The current Java.net poll question is, "How critical is it for JSR-310 (new Date and Time API) to be implemented in Java 8?" At the time of my writing of this post, nearly 150 respondents have voted and an overwhelming percentage have answered either "Very" (53%) or "It would be nice, but we can get by using the current classes" (22%). With 3/4 of the respondents feeling that it would either "be nice" or is "very important" to get a new Java Date/Time API, I think it's safe to say that Java's current Date and Calendar approach has not grown on us. Perhaps my biggest surprise so far with the survey results is that 2% of the respondents have stated, "I prefer the current date and time classes." Maybe that's from the people who wrote those classes?
I tend to use Java's date/time/calendar APIs off and on. When I use them, I really don't like them, but do start to tolerate them. I begin to forget how much I loathe them until I use them again. I recently helped a colleague familiar with Java (but not with the date/time APIs) to understand how to do some Date/Calendar/String manipulation and presentation. Explaining this mess out loud to him made the ridiculous difficulty of using these too-flexible APIs even more obvious to me. I could see on his face that he was thinking I was either kidding him or didn't know what I was talking about. Although I've gotten to the point where I can make them make do, it's much more difficult than it should be.
Much has been written about the woes of date/time handling in Java. Rob Sanheim wrote in 2006 about date/time-related problems in three of his Top Five Worst APIs in Java (Calendar, Date, and DateFormat/SimpleDateFormat). Java's Date-handling is focused on in Cameron Purdy's 2005 post The Seven Habits of Highly Dysfunctional Design. Tero Kadenius reminded us in the 2011 post Handling dates in Java that "The date/time API in Java is notoriously painful to work with." The aptly named post Java Dates Still Suck was published in 2009.
The current Java.net survey confirms my feeling after working with numerous Java developers and after reading many blogs and articles that the vast majority of Java developers are anxious to get a better standardized way of handling dates and times in Java.
7 comments:
I took a peek at the JSR-310 API (curious if it'd just be a clone of Joda Time) and it doesn't exactly look simple to use. Obviously it'll require some relearning to use, but I hope that a replacement API doesn't end up over-engineering things to the point of making it equally annoying to use as what it is meant to replace.
Hi I think Joda Time is what is missing from Java. I am looking forward to see a really brand new Date API in Java 8 and why not a fork of Joda time
Emanuel,
Thanks for the insight. I haven't looked at JSR-310 in detail yet, but your comment does make me curious about it. I think your concern about it being over-engineered is a valid one given the history of dates and times in Java.
Dustin
Papapetrou P.Patroklos,
Joda Time certainly seems to be the most popular alternative to Java's standard date/time APIs. I too am curious now about the current JSR-310 implementation.
Dustin
Emanuel and Papapetrou,
Stephen Colebourne's post What about JSR-310? examines why JSR-310 is not simply a port of the Joda -Time library into the JDK.
Even before that, in the post Announcing JSR 310 - Date and Time API, Colebourne stated: "Obviously, this whole JSR will be influenced by Joda-Time, the open source library that I've been working on for the last few years. However, the JSR will not be a simple adoption of Joda-Time. For a start the Java 5 language features make a difference. And there are probably a few rough edges that can be smoothed out too. But overall, its a very solid base to begin from."
It's worth noting that Joda Time 2.0 moved Joda-Time "to JDK 1.5 compatibility, adding generics."
Dustin
When I wrote this post, 150 people had responded to the Java.net poll and 75% of those expressed interest in a new JSR 310-based data/time API for JDK 8. Since then, nearly 700 responses have been tallied and over 75% (78%) have expressed the strongest favorable opinion ("very critical") and another 11% have expressed the favorable opinion ("nice to have"). Having nearly 90% of the respondents voting favorably seems pretty convincing that Java developers want JSR 310 in JDK 8.
Joda has been sufficiently mentioned and that says it all. Java's calendar-date APIs are terrible and so non-intutive (January being month 0 is just the start). I have used Joda for all date-time related operations over the past 3 years and it has performed very well. Its about time that Java's date APIs matured.
Post a Comment