These are the final results of the JSR Review Ballot for JSR #330. The Executive Committee for SE/EE has approved this ballot.
JSR330
StageJSR Review Ballot
Ballot durationMay 26, 2009 to Jun 8, 2009
Votes

SE/EE

Apache Software Foundation
Eclipse Foundation, Inc
Ericsson AB
Fujitsu Limited
Google Inc.
Hewlett-Packard
IBM
Intel Corp.
Keil, Werner
Lea, Doug
Nortel
Oracle
Red Hat
SAP SE
Sun Microsystems, Inc.
VMware
Vote Log

SE/EE

On 2009-05-26 VMware voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-05-26 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-05-26 Apache Software Foundation voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-05-26 Google Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-05-27 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-05-28 Keil, Werner voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-05-28 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-05-29 Intel Corp. voted Yes with the following comment:
Nice to see the open source TCK and RI, so no FOU issues for this JSR
------------------------------------------------------------------------------
On 2009-06-01 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
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-07 Ericsson AB voted Yes with the following comment:
We support the effort to standardize dependency injection for Java SE but would like to stress the importance of coordination with JSR 299 to get a consistent solution for both Java SE and EE.
------------------------------------------------------------------------------
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.

IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.  IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage.  We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
------------------------------------------------------------------------------
On 2009-06-08 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
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. 

------------------------------------------------------------------------------