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

[vogella]

Handlers contributed through the class attribute of org.eclipse.ui.handlers or the defaultHandler attribute of org.eclipse.ui.commands had to implement IHandler; anything else failed the cast in HandlerProxy 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 in the active part context, the same mechanism E4 model handlers use. Field and method injection plus @PostConstruct work as well, so plug-ins written against the E4 programming model can contribute handlers declaratively without deriving from AbstractHandler.

Instantiation still goes through createExecutableExtension, so IExecutableExtension and the <class><parameter> form keep working, and handlers implementing IHandler take the previous path untouched. QuitHandler (File > Exit) is migrated as the first platform POJO handler. Constructor injection and IObjectWithState are not supported, since instantiation stays on the registry path and HandlerProxy holds the command state itself.

[github-actions]

Test Results

   861 files  ± 0     861 suites  ±0   51m 15s ⏱️ - 1m 7s
 8 342 tests + 7   8 099 ✅ + 7  243 💤 ±0  0 ❌ ±0 
20 895 runs  +21  20 225 ✅ +21  670 💤 ±0  0 ❌ ±0 

Results for commit b487076. ± Comparison against base commit 9f0c234.

♻️ This comment has been updated with latest results.

[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.

[vogella]

This also now migrates the first handler (QuitHandler) so that the change is also used by platform. #4390 is the next wave of handler migrations to e4 POJOs.