Support "constructor-injection" with IConfigurationElement#createExecutableExtension

[laeubi]

I found that one source of using static methods are extensions declared with plugin.xml

The reason for this is, that a extension must have either a default constructor, or implement IExecutableExtensionFactory where both do not allow to pass any items at construction time. Also the creator can not pass additional data when creating the extension...

Example:

IConfigurationElement config = configs[0];
teamHook = (TeamHook) config.createExecutableExtension("class"); //$NON-NLS-1$

So I'd like to propose the following:

1. Adding a new method to IConfigurationElement with the following signature: Object createExecutableExtension(String propertyName, Object... args) throws CoreException;
2. if args are given, let it search for a constructor accepting the provided types
3. if no args are given or no constructor found use the default constructor

That way the example can then be enhanced to pass a workspace object for example:

IConfigurationElement config = configs[0];
teamHook = (TeamHook) config.createExecutableExtension("class", workspace); //$NON-NLS-1$

"old" implementations won't need to adapt, but newer ones could add a new constructor where they get a workspace object injected instead of calling static methods to fetch the required items.

[mickaelistria]

This is overall a good idea, but then implementations would not be backward compatible: imagine an extension made for 4.25 that does use a constructor with args because it's supported, then this extension wouldn't run with 4.24 because it would be missing a no-arg constructor. Although it may not be a strong blocker, we need an elegant way to ensure people understand that limitation.
Isn't it already possible to pass a context and use @Inject on fields when loading an extension point? IIRC at least some extensions allow it, not sure it it's by IConfigurationElement or something else.

[vogella]

@mickaelistria I implemented that for the org.eclipse.ui.views extention point a few years ago. Users had to / could opt in to this via the additional Inject parameter on the extension point.

[laeubi]

imagine an extension made for 4.25 that does use a constructor with args because it's supported, then this extension wouldn't run with 4.24

I think in general one can't expect such kind of compatibility (I won't call this backward compatible) because plugins written fro newer eclipse versions will generally require newer features/API already.

Isn't it already possible to pass a context and use @Inject on fields when loading an extension point

According to the implementation, no I don't see any way for that, for sure one could do so afterwards but this would always need additional techniques (e.g. E4).

[mickaelistria]

I think in general one can't expect such kind of compatibility (I won't call this backward compatible) because plugins written fro newer eclipse versions will generally require newer features/API already.

I agree. However, for things like new API or new extension points, there are versioning guards that make them well use. As per what is allowed in extension class, it's not as easy. We'd need to document it properly on related extension point that enable it (from which version constructor params are enabled; are no-op constructors still useful...?)

[laeubi]

If one want be super compatible he can create a default constructor as well (if suitable), if a default constructor is not suitable then it won't make sense of course.
But for example for the resource bundle it makes sense to often pass the workspace (what is some kind of 'context' already). So if an extension can live without the Workspace (e.g. because it get it dynamically from somewhere else) it migth be ok with a default constructor even though a Workspace is passed.

[github-actions]

This issue has been inactive for 180 days and is therefore labeled as stale.
If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below.
Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.

[github-actions]

This issue has been inactive for 180 days and is therefore labeled as stale.
If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below.
Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.

[github-actions]

This issue has been inactive for 180 days and is therefore labeled as stale.
If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below.
Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.

[github-actions]

This issue has been inactive for 180 days and is therefore labeled as stale.
If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below.
Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.