Support POJO handlers in the org.eclipse.ui.handlers extension point

[vogella]

Handlers contributed through the class attribute of org.eclipse.ui.handlers had to implement IHandler. Anything else failed the cast in HandlerProxy, which logged a ClassCastException and left the proxy permanently disabled.

Such contributions are now wrapped in an adapter that dispatches to their @Execute and @CanExecute methods through dependency injection, the same mechanism the E4 application model already uses for its handlers. Field and method injection plus @PostConstruct work as well. This lets plug-ins written against the E4 programming model contribute handlers declaratively without deriving from AbstractHandler, and removes the need for hand-written bridge classes.

Instantiation still goes through createExecutableExtension, so IExecutableExtension and the <class><parameter> form keep working unchanged, and handlers implementing IHandler take the previous path untouched. The schema is deliberately left alone: basedOn produces no validation markers in PDE, it only scopes the type browse dialog and prefills the new class wizard, so keeping it preserves that assistance for the IHandler majority at the cost of the Browse button for POJO authors.

Two limitations are worth noting. Constructor injection is not supported, since instantiation stays on the registry path. IObjectWithState is not forwarded to the handler, so a POJO cannot read or write command state directly, although toggle and radio rendering is unaffected because HandlerProxy holds that state itself.

[github-actions]

Test Results

   858 files     858 suites   51m 7s ⏱️
 8 161 tests  7 918 ✅ 243 💤 0 ❌
20 385 runs  19 731 ✅ 654 💤 0 ❌

Results for commit 1b492d9.

[laeubi]

Why would an E4 handler be additional being registered through plugin.xml (what defeats the purpose) so should this not better be fixed in the compatibility layer than requiring users to register it twice?
Next - if it should be supported - why do we create the handler through the extension registry at all and not using ContextInjectionFactory (what would then support constructor injection)

[vogella]

This is for the migration path e3 handlers -> POJO -> later to model similar to what we offer for view and e4 views.

As a migration path is currently missing we have seen zero migration of e3 to e4 handlers in the last 10 years in platform.

[laeubi]

This is for the migration path e3 handlers -> POJO -> later to model similar to what we offer for view and e4 views.

As a migration path is currently missing we have seen zero migration of e3 to e4 handlers in the last 10 years in platform.

You know that "later" is a synonym for "never" in computer programming right?

So I don't see how this would benefit anything from going straight to e4-model - what should actually be possible already. If not it would better be enabled like that instead of offering to use a middle-ground between e3 + e4.

[vogella]

Lots of my RCP client would be able to migrate their handler code to POJOs with little risk with this change.

[laeubi]

Lots of my RCP client would be able to migrate their handler code to POJOs with little risk with this change.

But again, what is the risk of declaring them in e4.xmi directly? If I remember right there is/was even an automatic migration offered there for views as well. That would offer a much more sustainable migration path here.

[vogella]

Lots of my RCP client would be able to migrate their handler code to POJOs with little risk with this change.

But again, what is the risk of declaring them in e4.xmi directly? If I remember right there is/was even an automatic migration offered there for views as well. That would offer a much more sustainable migration path here.

The e4 model persists its state while plugin.xml is recreated every startup so e4 model contributions have the risk of getting stale. So the client hesitate to do this one by one for a handler. With this change they can first migrate the Java code and afterwards do the model migration.