What Is The Relation Between JSR-299 and JSR-330 In Java EE 6? Do We Need Two DI APIs?
There was/is a lot of confusion, as JSR-330 (Dependency Injection for Java) led by Rod Johnson (SpringSource) and Bob Lee (Google Inc.) became a part of Java EE 6. JSR-330 is very simplistic. It comes with own few annotations from the package:
javax.inject. The package contains the following elements:
Inject, Qualifier, Scope, Singleton, Named and
Provider. Its the definition of the basic dependency injection semantics.
@Namedis not recommended and should be used only for integration with legacy code: "The use of @Named as an injection point qualifier is not recommended, except in the case of integration with legacy code that uses string-based names to identify beans."
[3.11 The qualifier @Named at injection points, JSR-299 Spec, Page 32] The relation between JSR-299 and JSR-330 is comparable to the relation between JPA and JDBC. JPA uses internally JDBC, but you can still use JDBC without JPA. In Java EE 6 you can just use JSR-330 for basic stuff, and enhance it on demand with JSR-299. There is almost no overlap in the practice. You can even mix JSR-299 / JSR-330 with EJB 3.1 - to streamline your application.
When voting No in Final Approval Ballot for both JSRs IBM left comments like "The current state of JSRs 330 and 299 do not provide a single extensible programming model.", and "The current lack of portability between JSR 330 and JSR 299 applications will create significant difficulties for the community.".
Their further comments like "..applications written for SE will require a porting effort to run them in an EE environment.." and "Application developers ... will experience integration issues" sound scary too.
Was/is IBM wrong?
Posted by Stevo Slavic on January 07, 2010 at 03:45 PM CET #
look at the JSR-330 RI - it shows what is needed to run JSR-330 outside the container. JSR-299 comes with a lot more functionality, so you will need a kind of container outside - so there is more effort. I was not a part of the JSR-299/330 EG - so it is hard for me to explain the statement. Right now I see no issues for an average enterprise project. I guess IBM wrote the comment from the application server-provider perspective...
thanks for your comment!,
Posted by Adam Bien on January 07, 2010 at 04:48 PM CET #
Just to clarify, @Named should not be used as "an injection point qualifier" meaning that you shouldn't match injection points with beans based on name. You should instead use type safe annotations for qualifiers instead of string based names.
However, @Named is very relevant and should be used for naming beans for access using EL such as with JSF.
The 'legacy' thing is probably referring to the Spring and Seam practice of naming beans and binding injectables with injection points by name instead of the new CDI way of type safe matching.
Posted by Andy Gibson on January 07, 2010 at 06:40 PM CET #
exactly - I used @Named for EL also in the sample mentioned in the post (http://www.adam-bien.com/roller/abien/entry/ejb_3_1_killed_the). It is nothing legacy about the EL.
In Java EE 6, however, injection can be qualified in type-safe manner. @Named works with String-matching.
Thanks for the clarification!,
Posted by Adam Bien on January 07, 2010 at 08:10 PM CET #