Skip to main content

Poll Result: Implementing JSR 310 (New Date/Time API) in Java 8 Is Very Strongly Favored by Developers

Posted by editor on March 18, 2012 at 7:40 PM PDT

Note to the Java 8 development team (and the JCP): the latest completed poll indicates that Java developers overwhelmingly advocate the inclusion of JSR 310 in Java 8. Not only did the poll draw a large volume of voting, but the votes were unusually strongly skewed toward one of the six voting options.

A total of 891 votes were cast, and three comments were posted as well. The actual question and results were:

How critical is it for JSR-310 (new Date and Time API) to be implemented in Java 8?

  • 75% (667 votes) - Very - as JEP 150 states, "the existing Java date and time classes are poor, mutable, and have unpredictable performance"
  • 11% (102 votes) - It would be nice, but we can get by using the current classes
  • 3% (23 votes) - Makes little difference to me
  • 1% (5 votes) - I prefer the current date and time classes
  • 3% (28 votes) - I don't know
  • 7% (66 votes) - Other

This is a remarkable result which, even though polls are voluntary surveys, and not scientific polls, would seem to have some significance. A large number of developers looked at the question and chose to vote. Among those who chose to vote, an unusually large majority selected the same option: that it's very critical for JSR 310 to be implemented in Java 8.

That option quoted OpenJDK JEP 150. Authored by Stephen Colebourne, this JEP (JDK Enhancement Proposal) advocates moving JSR 310 ahead sufficiently rapidly that it can be included in Java 8.

As user heathm commented:

Given the fact that we were expecting this in Java 7, I think it's something that's long overdue and must be included in Java 8.

jhannes noted:

java.util.Date and java.util.Calendar is somewhere between useless and dangerous. A new date API is definately called for.

And panayiotis_alefragis pointed out:

This is a must have in any scheduling application, we are forced to use custom libraries...

I'll say this (I never vote in polls since I create them): if (like panayiotis_alefragis), you have to develop custom libraries for something as basic as date and time manipulations in a language as high level and mature as Java -- yeah, I think we have a problem here!

Looks like Stephen Colebourne, heathm, jhannes, panayiotis_alefragis, 664 other poll voters, and undoubtedly a great many others agree on this question. Let's hope Stephen's JEP 150 objective is accomplished, and the JSR 310 new Date and Time API is indeed included in Java 8!

New poll: how will Java 8 closures affect your programming?

Our new poll asks To what extent do you expect Lambda Expressions (closures) in Java 8 to affect your programming? Voting will be open until Friday, March 30. Weblogs

Since my last blog post, several people have posted new blogs:

Java News

Here are the stories we've recently featured in our Java news section:


Our latest href="">Spotlight is the JavaOne 2012 Call for Papers:

If you have an interesting presentation idea for JavaOne 2012, we want to hear from you! The Call for Papers is open now through April 9, so don't delay. To help ensure successful submission, please take the time to review the General Information...

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feed and the blogs feed. You can find historical archives of what has appeared the front page of in the home page archive.

-- Kevin Farnham

Twitter: @kevin_farnham

Related Topics >>


While I keep seeing flaws and issues of the current ...

While I keep seeing flaws and issues of the current java.util.Date, Calendar, etc. in many Enterprise-scale projects and products, there are important aspects like the concept of a Non-Working vs. Working Day (or Holiday) other frameworks like ICU4J cover better.

So it still seems incomplete for real live usage. Plus more critical, Oracle's recent announcements that, from Java 10 on a true first class type system shall be introduced, it seems, type-sensitive JSRs like 310 or 354 may better wait for that Java version to make sense. Otherwise we'll all end up migrating twice in only half a decade. With Java 8 to 310 and with Java 10 to something (hopefully) much better or at least different.