There's been some interesting feedback from JSR299 folks on the new @Inject proposal. (Though there is a bit of argument for argument sake in there :).
I can understand 299 folks wanting there to be just one spec that talks about IoC. However IoC is a large complex area that is still undergoing quite a bit of innovation (e.g. see the changes in Guice 2 and the JavaConfig which is part of Spring 3).
For me the great thing about the new @Inject JSR is that its small, simple and focusses on the common well understood part of IoC (the annotations you add to your objects so that popular IoC containers can inject your objects). This is the thing I most want - a standard set of annotations I can use everywhere in objects - then consumers of those objects can choose whatever IoC container they wish to wire things together be it Spring or Guice or a JSR 299 provider or whatever. The actual wiring code (in Java, XML or some other script/language) tends to be kinda small stuff relative to the tons of Java code for the objects themselves. Given the large variety and constant innovation in the wiring side of things, its probably a bad time to try lock that part down as I don't think there's consensus on how that part should look (though Guice 2 and Spring JavaConfig seem to get closer all the time).
299 however standardizes lots of things which only seem to be done in Seam; I don't see Spring, Guice or Pico implementing 299 any time soon as its a bit too big - however all IoC containers should be able to implement @Inject pretty easily; most IoC containers have already got something like @Inject in them today.
So as a practical kinda guy at heart, the best way forward IMHO to be able to write IoC container agnostic objects that can then be injected by Spring, Guice, Pico, Tapestry or indeed a 299 provider seems to be the @Inject JSR.
This doesn't mean 299 isn't useful; there's some interesting stuff in there particularly relating to eventing and JEE integration to IoC; but I see getting @Inject done and adopted by Spring, Guice & Pico (and hopefully the JSR 299 RI too!) to be most important for IoC in the Java ecosystem as a whole.
5 comments:
I don't like the @Inject action name. I better prefer a role name may be @InjectedColaborator or @InjectionPoint
James,
I see @Inject as a subset of 299. Since that came first and the JSR proposal is more mature, it's @Inject burden to follow 299, not the other way around.
I agree 299 tries to push a lot of things - it would be better if were modular. But its goal was not providing DI per se, but acting as a glue between JSF, WS, JPA, etc.
At the risk of appearing thick, I don't get it. I mean I just don't get the need for identifying the parts of my beans that are injectable. Why is it not good enough that my classes are bean-conforming (public getters/setters, zero-arg ctors etc.)?
I'm sure I'm just missing something here and of course I'm happy to be enlightened. :-)
Actually, don't worry about that comment of mine. :-)
I went and had a closer look at Guice and I can see the benefit of marking items that are injectable. I suppose to answer my own question JSR-299 saves a lot of effort in the wiring side of things.
I found this video a great intro:
http://crazybob.org/2007/06/introduction-to-guice-video-redux.html
I agree with you that the scope of the JSR should be just on the established parts of IoC.
SUN's Jersey has an @Inject annotation & it's not even a DI framework!
Post a Comment