The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy
JSR #299
Contexts and Dependency Injection for the Java^TM EE platform
Public Review Ballot
Ballot duration: 2009-02-03 to: 2009-02-09
These are the final results of the Public Review Ballot for JSR #299. The Executive Committee for SE/EE has approved this ballot.
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
Icon Legend
Yes
No
Abstain
Not voted
View Vote Log

SE/EE
On 2009-02-09 IBM voted Yes with the following comment:
IBM has serious reservations about introducing another competing component model into the EE platform when this JSR was supposed to be focused on integrating technologies into the platform.  Aside from the duplication and confusion caused by this, the specification has expanded to cover a large spectrum of technology that is somewhat ambitious to fully define within a single specification.  However, we acknowledge that the spec lead has made substantial progress in addressing feedback and therefore, we are willing to vote yes to allow the specification to move forward on the assumption that the spec lead will continue to address feedback and concerns.

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-02-09 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-09 Oracle voted Yes with the following comment:
We believe this specification has the potential to augment the platform with useful functionality. However, we feel strongly that it must be properly and sufficiently integrated with the overall Java EE platform, specifically in the areas of XML definition, annotation usage, interceptors and events, and most particularly with respect to the perceived introduction of an additional component model.
We therefore support the continuance of this specification on the conditions that the component model issues be resolved and that the integration of these aspects of the specification be completed.
We appreciate Red Hat's ongoing work to address these issues with the community.
------------------------------------------------------------------------------
On 2009-02-09 SAP SE voted Yes with the following comment:
There are a number of good concepts, but we are missing an overarching principle for a number of diverging goals that this JSR tries to address. 

In our opinion, Web Beans  would be a great addition to the Java EE platform, in both capabilities and ease-of-use, but only if its ideas are better aligned and integrated into the existing Java EE world. 

We have communicated the details of our concerns to the Spec Lead. There is enough goodness that well justifies this JSR to proceed for now and we want to thank the Spec Lead for listening to our concerns. 

------------------------------------------------------------------------------
On 2009-02-09 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-09 Google Inc. voted Yes with the following comment:
Google votes yes with the understanding that if the spec name is changed, the new name will be "Contextual Dependency Injection for Java EE," and that all of the new package names introduced will have the "javax.ee" prefix.


------------------------------------------------------------------------------
On 2009-02-09 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-03 Apache Software Foundation voted Yes with the following comment:
I'd like to thank Sacha Labourey for his assurance that Red Hat will comply with that JSPA and not add Field of Use or other additional terms to the TCK license
------------------------------------------------------------------------------
On 2009-02-03 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-03 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-04 Red Hat voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-04 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-02-05 Intel Corp. voted Yes with the following comment:
This is a general comment we make in each ballot  By the agreement that forms the JCP, other than reciprocity rules for licensing and three compatibility conditions (including passing the TCK test suite) "the Spec Lead agrees not to impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations." The Apache Foundation claims in an open letter that they have been unable to obtain a TCK License that does not restrict compatible implementations of the SE Platform (additional restrictions that are not in the  specification itself). 

Java EE requires Java SE.  If the Java EE TCK License requires use of an SE implementation that passes the SE TCK and if the SE TCK License restricts field of use then the EE TCK License would also be restricting field of use through the SE TCK License.  Since the licenses are confidential, we do not know.

By the time EE 6 JSRs come to Final Ballot, we expect a statement that the EE 6 TCK License does not restrict field of use, does not require implementing anything other than what is required in the spec itself (no "value add" preventing implementation of just the spec) and does not require any other license that restricts field of use of JCP Specs.  
------------------------------------------------------------------------------
On 2009-02-06 Keil, Werner voted Yes with no comment.
------------------------------------------------------------------------------