These are the final results of the Public Review Ballot for JSR #275. The Executive Committee for SE/EE has not approved this ballot.
JSR275
StagePublic Review Ballot
Ballot durationJan 19, 2010 to Jan 25, 2010
Votes

SE/EE

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

SE/EE

On 2010-01-21 Red Hat voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-01-25 IBM voted No with the following comment:
The proposed specification provides the Java platform with a standard way to use and manipulate standardized Units of measurement, however it does not fulfill the mandate of the initial JSR. For example, the specification is silent on internationalization or localization issues which were part of the initial JSR proposal. The specification also requires improvements in wording and increased clarity by use of illustrative examples. These changes are required before the specification's initial release. Issues in the Java doc containing non-specified classes have been addressed in the expert group comments but the concerns that others have raised bout the size and complexity of the specification and these should also be addressed before completion.

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 2010-01-25 Sun Microsystems, Inc. voted No with the following comment:
We have serious technical reservations about the API presented in this public draft, in particular the lack of adherence to existing practices for API design in Java: naming conventions, use of constants on interfaces, lack of integration and inconsistency with existing Java platform APIs and the overall complexity of the design. Given that this work already has a long history (this JSR is a follow on from the unfinished JSR 108 which was withdrawn due to limited community interest) it is unsettling that such fundamental problems still exist.

Additionally, it does not appear that this project has yet built the breadth of community interest that drive the need to standardize such an API, as was our concern at inception of this JSR. So we are voting no.
------------------------------------------------------------------------------
On 2010-01-20 Keil, Werner voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-01-25 Eclipse Foundation, Inc voted No with the following comment:
Although we agree with the need for such an API, it requires refinement before its initial release.
------------------------------------------------------------------------------
On 2010-01-25 Oracle voted No with the following comment:
Even though we had concerns about this JSR during the JSR Review Ballot, we abstained in order to provide a chance for the submitters to fix the problems that were pointed out.  Comments submitted by others on this ballot convince us that this JSR has fundamental issues that must be addressed before it can transition to the next stage.
------------------------------------------------------------------------------
On 2010-01-21 Peierls, Tim voted No with the following comment:
There are crippling problems with this specification: It's large and complicated, with no substantial examples of usage, unpredictable decomposition into packages, extremely poor names (e.g., Measure implements Measurable, Quantity doesn't represent a quantity), unadvisable use of interfaces to hold constants, and awkward choices between interface and class. It ignores prior art and makes no effort to play well with existing Java libraries. The same things were true of the 2007 spec; there don't seem to have been any substantial changes since then. I wasn't on the EC for the initial review ballot, but from the comments it's clear that the EC only passed this JSR with the understanding that these deficiencies would be remedied. They weren't, so I'm voting No.
------------------------------------------------------------------------------
On 2010-01-21 Google Inc. voted No with the following comment:
A measures-and-units API has the potential to affect many other APIs. It is therefore critical that such an API be of the highest quality. When this JSR was initially proposed (6/13/05), Google voted Yes with the proviso that the API in the Contributions section was far too complex and would have to be simplified. This simplification has not happened. In addition to its complexity, the proposed API suffers from other serious faults including poor usability, poor decomposition, poor naming, inconsistency with existing APIs, and failure to adhere to best practices.

------------------------------------------------------------------------------
On 2010-01-22 Lea, Doug voted No with the following comment:
I share the concerns already stated. Additionally, especially given the lack of progress of JSR-310, a credible units API must accommodate time and date units as well, within a simpler framework. 
------------------------------------------------------------------------------
On 2010-01-25 Intel Corp. voted No with the following comment:
We (along with one other EC member)voted NO on the initial JSR review for (re)starting JSR 275 in 2005.  JSR 275 is a continuation of JSR 108, so drafting this spec has been underway since 2001.  The ballot comments from other EC members demonstrate a lack of consensus on this approach.  That doesn't mean the open source project isn't useful, but it does raise the question of whether it is appropriate to standardize now in JCP.  That was our concern in the 2005 ballot.
------------------------------------------------------------------------------
On 2010-01-25 Ericsson AB voted Abstain with no comment.
------------------------------------------------------------------------------