These are the final results of the Public Review Ballot for JSR #330. The Executive Committee for SE/EE has approved this ballot.
JSR330
StagePublic Review Ballot
Ballot durationSep 15, 2009 to Sep 21, 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-09-21 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-09-21 IBM voted Yes with the following comment:
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-09-21 Lea, Doug voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-09-21 Apache Software Foundation voted Yes with the following comment:
The ASF appreciates that the RI and TCK will be freely available under the Apache License.
------------------------------------------------------------------------------
On 2009-09-18 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-09-21 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-09-21 Intel Corp. voted Yes with the following comment:
It's good the 2 main implementations are agreeing on a single spec.  per Werner's comment - need documentation for Named.

The rest of 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). 

This problem doesn't impact JSR 330 because 330 makes the TCK available under an open source license (so no inappropriate restrictions on use of the implementation tested).
------------------------------------------------------------------------------
On 2009-09-21 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-09-21 VMware voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-09-21 Google Inc. voted Yes with the following comment:
We're puzzled by the claim that this specification contains "no proper documentation."  

* The package-level documentation contains a lengthy tutorial: http://is.gd/3xxXT 
* The documentation on @Qualifier specifies precisely how to define a qualifier, suggests a location for qualifier definitions, and explains the implications of using @Target on a qualifier's definition. It also contains an example qualifier definition: http://is.gd/3xyeO 
* The documentation for using a qualifier is in the "Qualifiers" section on @Inject: http://is.gd/3xy1J 
* The documentation on @Scope is precise and comprehensive, and contains a usage example: http://is.gd/3xzx6 
* The expert group discussed the specification of @Named extensively: http://is.gd/3xzIK . The brevity of the documentation is deliberate, reflecting the generality of the annotation. 
* The documentation for Provider lists reasons to use it, includes an example, and explains why users shouldn't try to catch exceptions thrown by get(): http://is.gd/3xAbq 
* The specification contains a BNF-syle grammar and addresses member accessibility, method overriding, return types, circular dependencies, and abstract vs. virtual vs. static methods: http://is.gd/3xy1J 

In sum, the specification provides all the information that a developer needs to use, test, or implement the facility, as well as plenty of (non-normative) examples and tutorial material.  It compares favorably to many existing Java platform specifications.
------------------------------------------------------------------------------
On 2009-09-21 Keil, Werner voted Yes with the following comment:
There is currently no proper documentation. Even the JavaDoc lacks any sound guidance on how annotations other than @Inject should be used. Especially @Named is completely undocumented, so in this form I would not consider it complete or ready.

Considering (one) Spec Lead's feedback I trust in their ability to add some more documentation.
------------------------------------------------------------------------------