Community
Participate
Working Groups
Simple scenario: A plugin creates objects whose classes are given through extension registry. If each object has its own class in different plugins, each of those plugins will be loaded by the framework. Often it is not appropriate to load all of those objects at once (and thus, the corresponding plugins). Maybe, there would be a "simple" extension to IConfigurationElement.createExecutableExtension(): MyInterface lazyObject = element.createExecutableExtension( "class-attribute", MyInterface.class ); As you can see, createExecutableExtension() handles the creation of a proper object (e.g. through dynamic proxies).
Created attachment 100406 [details] Sample Class to handle lazy loading through dynamic proxies
Use the LazyLoading class (from last attachment) as followed: IConfigurationElement element = ... MyInterface lazyObject = LazyLoader.newInstance( element.getAttribute( "class-attribute" ), MyInterface.class );
Sorry, I don't quite see the benefit here. "Old" way: use #createExecutableExtension() "New" way: use (1) #createExecutableExtension() + (2) LazyLoader.newInstance() If bundle activation is not desirable, when #createExecutableExtension() call cal be postponed until it is needed? It seems that the "new" way can be done today by doing nothing in place of (1) and doing #createExecutableExtension() in place of (2).
The "trick" of this approach is not to postpone or just call createExecutableExtension when it is needed. Postponing means that the caller must handle the creation and add extra overhead to his structures/classes to remember the desired classes, e.g. add extra attributes to obtain the postponed IConfigurationElement. This way, the caller does not need to deal with any extension registry api.
Indeed, this was meant to be a "workaround" when I realized that there were a lot of plugins loaded just because there were executable extensions created by a central plugin. First solution was to change a bunch of api to "postpone" the IConfigurationElement and let the caller decide on how to create the necessary objects. This was neither "elegent" nor safe to do since the api would have become cluttered by these IConfigurationElement attributes. So, the easiest and yet safest way was to create dynamic proxies. If you keep this in mind, you might understand why this approach might be worth to be available as a common feature.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
