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 #275
Units Specification
Public Review Reconsideration Ballot
Ballot duration: 2010-03-02 to: 2010-03-08

These are the final results of the Public Review Reconsideration Ballot for JSR #275. The Executive Committee for SE/EE has not 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

Oracle

Peierls, Tim

Red Hat

SAP SE

VMware

Icon Legend
Yes
No
Abstain
Not voted

View Vote Log

SE/EE

On 2010-03-08 Peierls, Tim voted No with the following comment:
0.9.5 addresses all of the issues in 0.9.4 that prompted my earlier No vote. I'd like to see a full public review of the current spec, followed by another ballot, but since the JCP doesn't seem to allow this path, I believe that the best way forward is to continue under a new JSR. 
------------------------------------------------------------------------------
On 2010-03-08 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 2010-03-08 Hewlett-Packard voted Abstain with no comment.
------------------------------------------------------------------------------
On 2010-03-08 Lea, Doug voted No with the following comment:
The current draft is significantly improved. I expect continued progress, including any revisions stemming from experience using these APIs in their 
intended contexts. However, the stated aim of this 
JSR is to become part of a J2SE platform release, in
which case there do not seem to be any processes 
available to independently approve improved versions
of this spec. So I reluctantly recommend that any
continued efforts be placed under a different JSR,
perhaps with different goals.

------------------------------------------------------------------------------
On 2010-03-04 Keil, Werner voted Yes with the following comment:
For list of changes please see the JSR-275 Update page. Being able to provide a foundation also for others like 310 and related challenges common to almost every IT project the business case is even more present than the scientific one, despite the RI's name.
------------------------------------------------------------------------------
On 2010-03-08 Ericsson AB voted No with the following comment:
I appreciate the work done by the EG to try and fix all the issues raised in the last vote. But after the issues raised by Doug and Josh I believe that the more work is needed. I change my vote from yes to no. 
------------------------------------------------------------------------------
On 2010-03-08 Apache Software Foundation voted No with the following comment:
While the ASF appreciates the work done by this expert group to try and repair this JSR, but I still believe that more work needs to be done to make this JSR appropriate for the Java SE platform, which is the stated intention of the spec lead.
------------------------------------------------------------------------------
On 2010-03-08 Google Inc. voted No with the following comment:
Google appreciates the effort that went into improving this API since its Public Review draft. Sadly, we still feel it has too many flaws to pass to the next phase of the process. These flaws concern type system usage, naming, method overloading, and API structure. Taken together, they result in an API that is likely to suffer from severe usability issues.

Also we are concerned that the expert group was unclear on whether the API was slated for inclusion in the JDK. Section 2.16 of the JSR template is the proper place to indicate this, and Section 2.16 of this JSR says that the API was not destined for inclusion in the JDK.

Finally we are concerned that the level of integration and coordination with JSR-310 is insufficient. Joda Time is now widely used by the Java Community, and it seems likely that JSR-310 will eventually become part of the JDK. It is critically important that the JDK has a coherent story regarding time units.

------------------------------------------------------------------------------
On 2010-03-08 Intel Corp. voted No with the following comment:
It isn't clear that this is mature enough at this point for specification under javax.  Some form of experimental specification may be a better approach.
------------------------------------------------------------------------------
On 2010-03-04 Red Hat voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-03-08 Oracle voted No with the following comment:
Oracle is changing its vote from yes to NO on this JSR because of the issues raised by Doug Lea and Josh Bloch, especially as they relate to inclusion of the JSR in the J2SE platform release.  We commend the the expert group's effort; the JSR is significantly simplified and has addressed many of the technical concerns raised by the EC at the Public Review ballot. We believe this JSR needs to adequately synchronize its embodiment of time in the API with JSR 310 before it can complete.
------------------------------------------------------------------------------
On 2010-03-08 Fujitsu Limited voted Abstain with no comment.
------------------------------------------------------------------------------
On 2010-03-08 Eclipse Foundation, Inc voted Abstain with the following comment:
There seems to be enough confusion about the status and process to be followed by this JSR to abstain at this point.
------------------------------------------------------------------------------