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.