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 #235
Service Data Objects
Final Approval Ballot
Ballot duration: 2009-03-24 to: 2009-04-06

These are the final results of the Final Approval Ballot for JSR #235. 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-03-25 IBM voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-03-25 Keil, Werner voted Yes with the following comment:
I would like to know how this proposal compatible with other JSRs and additional (also domain-specific) data types in general?

Date is a good example. Have you interacted with JSRs like 310 which aim to completely rebuild Date/Time/Calendar API in future JDKs. Will your proposed solution be compatible with that, or have you at least added a flexibility to integrate such libraries already?

Then there is a curious little detail from the Spec document. How come it is not possible to convert from "YearMonthDay" to "Year", "Month", "Day", "MonthDay" or "YearMonth"??
As all of these are completely included in "YearMonthDay".
------------------------------------------------------------------------------
On 2009-03-25 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-03-26 Red Hat voted Yes with the following comment:
The spec lead of the EE6 specification has confirmed that the EE6 TCK would contain no "field of use restrictions", as originally raised by Apache with regard to another JSR (i.e. the SE TCK licensing). That is a good thing.

However, in the absence of an explicit JSPA rule that would forbid such field-of-use restrictions, we will remain worried that a similar issue might resurface anytime, for any JSR.

Consequently, in the future, for any submitted JSR (by SUNW or not), we will specifically expect the spec lead to provide clear information on that aspect and take the answer in account when casting our vote.
------------------------------------------------------------------------------
On 2009-03-30 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-03-31 Sun Microsystems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-04-02 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-04-02 Intel Corp. voted Yes with the following comment:
Full licenses available on public JCP JSR 235 Page.  Thanks for providing those.  With concerns in other JSRs about restrictions on implementation, it is a very good practice to provide the community with full text of the licenses so they can see for themselves that the specs can be implemented.  
------------------------------------------------------------------------------
On 2009-04-06 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-04-06 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-04-06 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2009-04-06 Apache Software Foundation voted Yes with the following comment:
Thanks for the clarity around the licensing.
------------------------------------------------------------------------------
On 2009-04-06 Google Inc. voted Yes with no comment.
------------------------------------------------------------------------------