Dependency injection to the rescue!


Dependency injection is probably not as widely useful as regular expressions but is pretty pervasive these days in most applications built on Java EE, Spring, or Guice.

Recently, Google (most prominently Bob Lee and Guice) teamed up with SpringSource (most prominently Rod Johnson and Spring) to propose a JSR for standardizing dependency injection annotations for Java SE in JSR 330.

Of course, this treads perilously close to the territory of JSR 299. 299 is the “Web Beans” JSR which covers a bunch of stuff I don’t know much about but also includes a Java EE dependency injection proposal for EE containers. Gavin King (from JBoss and the 299 spec lead) was quick to voice some objections with potential overlap. Bob Lee responded to those objections.

Today, the plot thickened as JSR 330 was approved by the JCP to go forward with 14 yes votes, and 1 abstention from Red Hat. The comments are fun:

On 2009-06-02 Sun Microsystems, Inc. voted Yes with the following comment:

We are glad to see the Spring and Guice communities get together to standardize dependency injection for the Java platform, and we are supportive of this effort.

Dependency injection is unusual in having a pervasive nature and entailing some powerful network effects that, in the absence of a comprehensive standard, naturally lead to harmful fragmentation.

In this respect, we request that this JSR and JSR-299 coordinate their efforts so that they can jointly deliver a single, consistent and comprehensive dependency injection standard for the SE and EE platforms. Such coordination must take place before the Public Review of this JSR.

On 2009-06-05 Red Hat voted Abstain with the following comment:

Red Hat is deeply skeptical of the value of this JSR, since it
envisages the existence of a separate container that is not part of the SE or EE platforms, and whose semantics and programming model are sufficiently ill-defined that portability of applications between different containers would be impossible for all but the most trivial of applications. This is a break from the Java tradition of “write once, run anywhere”.

However, we recognize that there is some community support for this proposal, and we’re therefore holding back on forming a final opinion until the Expert Group produces a public draft. If some level of alignment could be reached between this JSR and JSR-299, which does define a truly portable model for dependency injection, we would be more likely to vote to approve the JSR. Red Hat hereby commit to doing our part to help achieve this outcome.

On 2009-06-08 IBM voted Yes with the following comment:

IBM agrees with the need for a specification describing Dependency Injection for SE applications. However, the proposed injection patterns are divergent from those defined or being defined in the EE platform. The SE/EE injection programming model must be aligned into a single extensible programming model that defines a core set of functionality for SE and extends that with EE functionality. Therefore, IBM will not support either JSR 299 or 330 going to final state without that alignment.

On 2009-06-08 Oracle voted Yes with the following comment:

Oracle believes that dependency injection is now used widely enough to warrant inclusion into both the SE and EE platforms; enabling not only “injectable” component portability, but ideally also “application” portability (using dependency injection as the method of component assembly), without stifling innovation, precluding the use of existing open source DI frameworks, or, importantly, ignoring existing injection(-like) mechanisms already in, or planned for inclusion into future releases of the platform(s).

While being supportive of this JSR, Oracle is seriously concerned about both the completeness of this proposal w.r.t above, as well as the significant opportunity for divergence with JSR 299 that may lead to serious fragmentation of the platforms. Therefore, we would like to see coordination between this JSR and JSR 299 before this JSR goes to Public Review. We also believe that a revision/Maintenance Release of JSR 250 would be a suitable delivery mechanism for DI-related annotations. We hope and expect that such a coordinated effort will result in consistency across the SE and the EE platforms in provide a standard dependency injection mechanism that satisfies all the needs.

Should be interesting to see where this proposal goes and how it ends up converging (or not) with JSR-299. Personally, I am quite sympathetic with having some standard annotations for dependency injection and not needing some (or any) of Java EE to get them. We have some tiny dependency injection in our Terracotta cluster events API and we would seriously consider using a standard annotation if there was one.


6 Responses to “Dependency injection to the rescue!”
  1. rainwebs says:

    Did you recognize that all commentators have an EJB container in their portfolio? so my interpretation of JSR-299 (this is purely EJB stuff with no innovation) can’t be this wrong:

    For me the idea of a pure standardizing the DI instead of a “every-thing-is-a-bean-now-and-we-put-a-litte-DI-in-it-for-acceptance” looks much more useful.

  2. Jasper kong says:

    Isn’t this just Rod desperately trying, again and again, to dethrone Sun (soon Oracle) as the leader of the Java EE platform by pushing his own platform and container and setting his own standard?

    Does Rod persuades people to hate Java EE out of the goodness of his heart or is there a double agenda and does he simply wants to push his own alternative container?

  3. Scott Ferguson says:

    If you look at the JSR-330 proposal, it’s essentially a renaming of JSR-299 annotations. So, really, this looks primarily like a complaint about class names, which seems rather petty to create a whole new JSR just to change some annotations.

    @BindingType becomes @Qualifier. @ScopeType becomes @Scope. @ApplicationScoped becomes @Singleton. Instance becomes Producer.

    The only real difference is JSR-330’s requirement of an explicit @Inject annotation, which I can see people disagreeing about, but again seems petty as a reason to start a whole JSR.

  4. Alex says:

    @Scott: I don’t pretend to be an expert on either jsr but I think there will be more detail and differences that come out as the expert group works on the spec. While there is a lot of shared goals, I think the intended audience is different and that may mean different things. JSR-330 commits to less with the goal of being open for more uses.

    Talking to Bob Lee at lunch yesterday, the Red Hat comments are based on the original version of the proposal and things have evolved since then. JSR-299 final draft has been submitted and Gavin had a lot of useful new comments here including some on JSR 330:

    However, JSR-299 does not currently define a bootstrap API for starting and running the container standalone in the SE environment. Instead, this API is being defined by JSR-330. Unlike JSR-299, JSR-330 is not defining everything that is needed in order to write portable applications. So you’ll still need JSR-299 if you want your application to be portable to other container implementations. Therefore, we plan a maintenance release of JSR-299 that includes support for the JSR-330 bootstrap API. For now, if you want to run JSR-299 in the SE environment, you’ll need to use a vendor-specific bootstrap API.

  5. Michael says:

    299 vs. 330 is interesting … and a little comical. The first time I heard of 299 was a little more than 2 years ago. That year at JavaOne, I attended a joint talk by Bob and Gavin. It was a disjoint talk to say the least. Gavin mostly exclaimed “look at what we can do with your beans!” while Bob more calmly talked about how DI could be done faster, simpler, and more type safe. Bob didn’t say what he was comparing to, but it was obviously Spring. Two years later in this Java soap opera and Bob is teamed up with Spring… However, even two years ago not only were Bob and Gavin an odd couple, but Guice plus JSF or EJBs seemed like an even odder couple.

  6. Cédrik says:

    The Oracle comment is the only interesting one raising the JSR-250 existence. I don’t want to choose between @Resource and @Inject!