JSR-310: A specification request to free Java from the date handling nightmare

JSR-310 is important. A JSR isn’t that sexy, I know, but this one is worth fighting for.

In order to set the context, here’s an old news flash: The date implementation in Java is a piece of crap.

The Java community has ranted about this madness since JDK 1.0. Java doesn’t distinguish between date and time, and manipulating dates is cumbersome and error-prone. The solution, introduced in JDK 1.1, was not to rewrite Date, but in order to ensure backward compatibility, simply wrap a Calendar around the Date object. Calendar itself introduced several more serious problems and consequently – even more frustration. There is simply no concept of points in time, intervals, or durations. Even calculating the days between two dates is not trivial. It should be. Not the least, Calendar forces you into a random integer jungle when manipulating dates. Take your pick, you have lots to choose from: HOUR_OF_DAY, HOUR, DAY_OF_MONTH, DATE, DAY_OF_WEEK, DAY_OF_WEEK_IN_MONTH.

If that is not enough, the guilty parties responsible for designing the calendar has taken Edsger W. Dijkstra perhaps a little too literally.

cal.set(Calendar.MONTH, 0)

…yields January. Yep, Calendar refers to months using a zero-based index. A long time ago, Dijkstra told all programmers to count from zero. While this is both true and important for counting and holding track of your internal indexing, it’s NOT for every single concept imaginable holding a number. The numeric representation of January is 1, and not 0. What internal index Calendar stores January at is not relevant. The offered solution is priceless. Let’s just provide yet MORE constants to choose from: cal.set(Calendar.MONTH, Calendar.JANUARY). The int possibilities are endless. This sums up to:
cal.add/set/roll(Calendar.WELCOME_TO_THE_INT_JUNGLE, Calendar.WELCOME_TO_YET_ANOTHER_INT_JUNGLE);

To make matters even worse, Calendar has proved broken as well. For instance:

• Calendar is not thread safe or immutable.
• Leap seconds can change the date represented by a serialized object
• Calendar method after doesn’t complain if you pass it a Date (or any other object…) This bug report is related to how before() and after() is broken. The bug is interesting enough, but the pure gold is found in the rejecting answer: “It’s hard to change the implementation at this point.“.

What about the Date object? We are looking at a class having 4 out of its 6 constructors, and 20 of its 28 methods deprecated. Consequently, Date should be regarded as a deprecated class. The fact that it’s not, and to some extent still necessary is a clear indication that something is horribly wrong in the date handling department. Ok, I guess I could go on and on about ranting about this. Do a quick search on java+calendar+date+broken, and you’ll have enough reading material to keep busy for a while.

Along comes Joda Time. An early bug report from 2000 asks for a replacement, but is rejected by Sun. The replacement the bug reporter asks for is Joda Time. Originating from Google SITA ATS Ltd (thanks, Ben!), Joda Time seeks to solve all challenges related to date manipulation encountered with the infamous Date and Calendar constructs. Whereas there has been some criticism of Joda Time being too complicated, introducing around 100 new classes with several levels of inheritance and so on, Joda Time has matured into a date and time API that forms the basis for JSR-310.

At JavaOne 2008, JSR-310 was presented in detail. Although no commitments about inclusion was made, JSR-310 was suggested to be included in Java 7. JSR-310 continues several of the same concepts introduced by Joda Time, instants, durations and intervals. In addition, the JSR-310 lead, Stephen Colebourne, is obviously the right man for the job. His previous project was, you guessed it – JodaTime. Everything is not in its right place, however. In December 2008, Colebourne announces a delay. But Java 7 is delayed as well, and at Devoxx 2009, Sun announced the delay of Java 7 until Q4 2010 at the earliest. Stephen Colebourne noted November 30, 2009 that this delay could be the last opportunity for getting JSR-310 into Java 7.

Someone should pay this guy to get this done. Right now, the future of date handling in Java 7 is dependent on Colebourne’s development in evenings and weekends. But everybody can help out – read more here.

JSR-310 is a specification request worth fighting for.

Advertisement