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 #310
Date and Time API
Public Review Ballot
Ballot duration: 2013-12-10 to: 2013-12-23
These are the final results of the Public Review Ballot for JSR #310. The EC has approved this ballot.
Votes

Arm Limited
Azul Systems, Inc.
CloudBees
Credit Suisse
Eclipse Foundation, Inc
Ericsson AB
Freescale Semiconductor
Fujitsu Limited
Gemalto M2M GmbH
Goldman Sachs & Co.
Hewlett-Packard
IBM
Intel Corp.
Keil, Werner
London Java Community
MoroccoJUG
Nokia Corporation
Oracle
Red Hat
SAP SE
Software AG
SouJava
TOTVS
Twitter, Inc.
V2COM
Icon Legend
Yes
No
Abstain
Not voted
View Vote Log

On 2013-12-19 Gemalto M2M GmbH voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-12 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-23 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-22 Eclipse Foundation, Inc voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-23 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 2013-12-23 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-23 Azul Systems, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-23 Fujitsu Limited voted Yes with the following comment:
Fujitsu's vote is based on the technical merits of this JSR and is not a vote on the licensing terms.
------------------------------------------------------------------------------
On 2013-12-18 SAP SE voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-14 London Java Community voted Yes with the following comment:
Great to see a solid API in place for Java.  We hope that the Java community at large heavily advertises this new API to promote faster, more accurate and safer date/time handling.
------------------------------------------------------------------------------
On 2013-12-13 TOTVS voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-16 CloudBees voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-23 Keil, Werner voted Abstain with the following comment:
Unfortunately this JSR has a significant number of issues.
The top 5:
- Lack of support for ISO-8601 (a standard last updated in late 2006, long before the JSR started) 
- Circular RI dependencies in the API/Spec (Duration is what one shall consider part of RI, but it's used in the abstract API interface TemporalUnit, effectively making independent 3rd party implementations without using the RI impossible;-/)
- Giant footprint (larger than any single package of the JDK so far) making this JSR irrelevant to a vast majority of the X-Billion devices the IoT/M2M generations expects to see running Java ME Embedded in the near future. Thus marginalizing the JSR as true cross-platform solutions will never pick it up and stick to "good old java.util.Date/Calendar".
- Redundancies, both concepts like ChronoField vs. ChronoUnit defining things twice and Reinventing the JDK wheel, e.g. a DecimalStyle used only here, which instead should have been better integrated with the remaining JDK. All reasons for the excessive size.
- Violating design princples practiced across all of Java SE or EE, especially use interfaces or abstract classes instead of concrete types (everywhere from Collections, to Lambdas or JavaFX as well as nearly every JSR these "Effecive Java" guidelines by Gosling, Bloch, etc. are applied but in this JSR;-/)

From a functional point of view, ICU4J (which not only helped improve Java Date/Time in the past, but also Locale or other i18n related parts of the JDK) offers not only the same features but exceeds it both from the number of supported cultures, calendars and chronologies, as well as business-critical ones like Holiday/workday distinction. Where memory is not a problem, the 10-20MB of ICU4J won't matter and provides features this JSR left out, while on small, memory constrained devices neither ICU4J nor JSR 310 will matter. There Date4J, see the switch of Google and others from JodaTime to Date4J (http://www.date4j.net) an API doing the same with just 3 classes where this JSR throws ~155(!) at Java has become the most popular alternative. This JSR is "Too Big, too Late" for a Post-PC era I'm afraid.

Having talked to other EC and JCP members and given a first response by Spec Lead(s) showing little understanding of even the most gross problem (IMHO that would be the Circular Dependency Antipattern, making it even harder for Jigsaw and Java 9 than it already is to cope with that) I must abstain.
------------------------------------------------------------------------------
On 2013-12-14 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-12 Arm Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-12 Software AG voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-16 Red Hat voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-16 V2COM voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-14 MoroccoJUG voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-13 Goldman Sachs & Co. voted Yes with the following comment:
Raised issue with Possible missing method with EG , but a welcome evolution
------------------------------------------------------------------------------
On 2013-12-15 Nokia Corporation voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-16 Twitter, Inc. voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-23 SouJava voted Yes with the following comment:
SouJava is very happy to see this JSR finally becoming officially part of Java. It is a great example of how innovation can happen in the open source world, and help evolve the platform.
------------------------------------------------------------------------------
On 2013-12-23 Freescale Semiconductor voted Yes with no comment.
------------------------------------------------------------------------------
On 2013-12-23 Credit Suisse voted Yes with no comment.
------------------------------------------------------------------------------