In bug 302824 we started discussing how to make the use of DI easier and beside e.g. providing Helper-Classes the ideal thing would be to provide good tooling. Think about how hard OSGi-Development would be without PDE and I think the same is true for DI as well.
I had some free minutes (well in reality hours) today and thought about how such a tooling could look like. The first thing I’ve implemented today is a dialog showing core services and add them to your POJO (currently only the UI is working more or less).
There are other JDT/PDE extension we could provide to make DI in general easier but I need to make myself familiar with PDE/JDT-extensions before I know what’s possible.
Tomsondev Blog 
Good idea Tom!
I still do not see the benefits of the @Inject annotation. I much prefer an interface based solution as injection will always use Reflection (and therefore has to deal with Security issues) whereas interfaces add public setter to a class.
And you would see in the code what the class actually does. Also checking for instanceof CommandServiceConsumer is much quicker than searching through the class for annotated fields/methods (even if you only do it once then you have so save the information somewhere in the memory).
Great stuff Tom. I hope this shows people that DI works quite well, and with the proper tooling, the stuff will be easy as pie.
Hi, I am not very familiar with the e4 DI features. How much of JSR 330 is supported in e4? Are qualifiers supported? And if they are, how is this mapped to OSGi services? Is there a document that explains the features in detail?
It would be cool if there would be a general JSR 330 tooling. Since many frameworks (e.g. JEE 6, Spring) seem to adopt the annotations, other eclipse projects could benefit from the work done in such a project. One use case wold be finding possible providers for an injected object.
e4 has full support for JSR 330. The current implementation simply provides an OSGi-Service Tooling providers can use to register ServiceProviders no matter of they are e4, … .
Thanks.
I’m not sure if I understand it correctly what the scope of the eclipse DI mechanism is. Can every OSGi Service be injected, or just e4 services. Is there a way to register services declaratively using annotations? And if there are several Services registered under the same interface, how can they be accessed? Is the javax.inject.Provider interface used for that, or is there something like the javax.enterprise.inject.Instance (http://java.sun.com/javaee/6/docs/api/javax/enterprise/inject/Instance.html).
The current implementation simply exposes an OSGi-Service [1] when running inside the Eclipse-Workbench and Tooling implementators can simply fetch the service from the OSGi-Context and add their own services e.g. if they the project nature is added to a project (as a first step I thoght about an e4-nature). This makes the core part free from the need to know how services can be looked up. The following come to my mind:
I tried to make the implementation free from details how to services can be looked up but I’m only at the very early stages so. Probably I should write a 2nd blog post about how I envision the tooling could work. Anyways though I’m very familiar with Eclipse as an RCP-Platform this is my first time trying to extend PDE and/or JDT in general so naturally I could need some help from people who know more about something like this.
[1]
public interface IDIServiceRegistry {
public void addServiceProvider(IDIServiceProvider descriptor);
public void removeServiceProvider(IDIServiceProvider descriptor);
public List getProviders();
}
My impression was, that when people complain about “DI in e4” and that we urgently need corresponding tooling they referred to other aspects of the new e4 programming model. For instance, the String-based invocation of methods via ContextInjectionFactory.invoke (btw. that’s not DI, is it?).
Well ContextInjectionFactory.invoke is another thing but probably also one which we need to address somehow though I have no clear idea yet. Still I also think that people need help to get access to OSGi-Services.