I remember looking at an early draft of what used to be called the Web Beans JSR and it kinda looked a bit like 'hey lets try standardize Seam'. It didn't strike me as being too relevant or useful to folks typically using Spring/Guice to build their applications.
However I've just had another look at the lastest draft and its now looking pretty good. The rename to Contexts and Dependency Injection for Java certainly helps.
Dependency Injection is such a cross cutting concern throughout the Java ecosystem - its also a very well understood problem space with a small number of popular implementations. We really should have a set of standard annotations for Dependency Injection above the basics in JSR 250 so we really can write framework agnostic code that can work in more than one DI container. So far JSR 299 is the best effort I've seen to try come up with a standard.
Ironcially the annotations used in JSR 299 are almost exactly the same as those used in Guice 2 (@Produces/@Provides, @Named, @BindingAnnotation/@BindingType etc). Also Spring has started adding more and more annotation based dependency injection support of late; so the various approaches are kinda unifying a little.
So with a bit of effort it should be pretty easy to implement the dependency injection parts of JSR 299 in both Guice and Spring; so then we'd have a real, useful, dependency injection standard working across all the main DI frameworks.
I wonder if the Spring & Guice folks will put petty politics aside and really get behind JSR 299 for the good of the Java ecosystem?
11 comments:
In the Eclipse e4 project, we would like to support dependency injection but cannot just use one of the existing implementations due to licensing issues, and because we need to be careful about footprint in our core pieces. I started adding support for @Inject, @Resource, @PostConstruct, and @PreDestroy. The current (toy) code uses reflection to avoid hard dependencies on the actual types, but it's at least a start. If you have any feedback, that would be very much appreciated!
I agree with you that supporting a common set of annotations across the different DI implementations makes a lot of sense. However, the eval license terms for JSR 299 turn me off, so I will probably have a look at Guice 2 for inspiration and ignore JSR 299 for now.
The RI of JSR 299 is Apache Licensed...
http://www.seamframework.org/WebBeans/WebBeansDevelopmentOverview
That should be OK for use in Eclipse shouldn't it?
Thanks for the pointer! Reading it now...
"Ironcially the annotations used in JSR 299 are almost exactly the same as those used in Guice 2 (@Produces/@Provides, @Named, @BindingAnnotation/@BindingType etc)."
That is not coincidental or surprising. From Gavin King's blog[1]:
"The component model is deeply influenced by Google Guice and Seam."
and
"Some members, notably Bob Lee"
You'd expect it to borrow a lot from Guice once that information is available. :)
[1] http://in.relation.to/Bloggers/WebBeansSneakPeekPartIIntroducingWebBeans
Sadly, it only borrows from Guice, without Guice's understanding of how real DI works. Bob Lee (creator of Guice) recently posted his dissatisfaction with JSR-299 on the Guice mailing list: http://groups.google.com/group/google-guice/msg/f795f369f99df62c
Interesting and a shame.
Ismael
@Jim
How about you read the spec, check the RI and make your informed opinion on the subject instead of propagating Bob's which he hasn't backed with technical arguments yet on the thread you refer to.
I happen to know some of Bob's arguments and I could make my opinion.
Bob is a brilliant person and friend so nothing against him.
JSR-299 looks like Java's modern form of an application bus enabling to plug different component models to let the components talk together.
http://www.jroller.com/dmdevito/entry/seam_is_a_kind_of
@Boris,
you can also take a look at OpenWebBeans:
http://incubator.apache.org/openwebbeans
LieGrue,
strub
I happen to know some of Bob's arguments and I could make my opinion.
Well, let's hear it then. Because actions speak louder than words, and Bob not being part of the JSR sends a strong message the direction of the "committee of Gavin" was not "pretty good". I, for one, am sticking with Guice.
@Michaelok as it happens JSR330 is going strong and looking great - it should be supported by both Spring and Guice.
http://code.google.com/p/atinject/
and so far the signs are good that Gavin and Bob are working together nicely and that JSR 299 could well be based on top of JSR 330!
Post a Comment