Practically Agile

Using Agile in less-than-perfect situations since Y2K

Java Dates Still Suck

At the risk of this becoming a bile blog, I have another Java rant. It has been a long-standing tradition (12 years?) among Java developers to cry out that the date implementation in Java is pretty terrible. So, it’s not just me

As a bit of history, the folks at Sun (soon to be Oracle) tried to fix this by all but requiring that Date objects be wrapped with Calendar objects in JDK 1.1. They couldn’t just fix the date implementation directly because of another long-standing tradition: new Java versions must be backward-compatible with previous versions. Regardless, this fix has long been considered a kludge at best, but most of us learned to live with it. Preamble out of the way…

I was working with someone today who had a Calendar object. They wanted to compare it with another object to see which was earlier. So, they called Calendar.after(Object). Makes sense right? Only this method returned false even when the other object was definitively a representation of a time after that represented by the Calendar object. This seemed odd to the developer in question.

The observant among you may have noticed that I did not say they were comparing with another Calendar object. They were, in fact, comparing against a Date object. Knowing that, I immediately suspected the problem. A quick trip to the API docs showed me this gem:

Returns whether this Calendar represents a time after the time represented by the specified Object… if and only if when is a Calendar instance. Otherwise, the method returns false.

So, rather than throwing an IllegalArgumentException or having the method specifically only take a Calendar object, this method and the corresponding before(Object) method both just return false when you send in… anything else. So Calendar.after("dates in Java suck") returns false.

There are no good reasons for this that I can think of, so I went to the Bug Parade. There, I found a few tickets that were marked as fixed or otherwise closed. However, this is still obviously a problem, right? Refining my search, I found what I think is the most recent one. It is marked as “Closed, Will Not Fix”. Why? Here is the relevant part of the comment:

It’s hard to change the implementation at this point. Please use compareTo(Calendar) added in 1.5.0.

I’m sorry, can’t we at least deprecate things that are this broken? Do we not do that after the heckling caused by deprecating 60% of the methods in Date?

A follow up question… Where is the replacement library? We had java.nio, why not create a new java.date? For that matter, why hasn’t a third party library really taken off here? My suspicion is that JPA integration is the main challenge. Especially since, in addition to the problem of them having the same class name, java.sql.Date extends java.util.Date.

Maybe I’ll try out Joda Time or another 3rd party replacement. Does anyone know how their Hibernate sub-project works in the field? (Update: The goal of JSR-310 is actually to get Joda Time into core Java. It had been tentatively scheduled for Java 1.7. A quick look around shows that there was some struggling to get it completed and tested for inclusion. I was not able to determine an outcome. Anyone know?)

I’ll try to make my next post about something more positive.

Tags: , , , ,

. 29 May 09 | Programming

Reader's Comments

  1. Tim | May 29th, 2009 at 9:32 pm

    Yes, Java Date/Calendar sucks. I was in a all too similar boat not long ago. Master Joda (Time), seek out, you must. He saved the day for me.

    -Tim

  2. Aaron D | June 1st, 2009 at 8:58 pm

    I’m dittoing Tim. Joda(time) is a great alternative to the horror and pain that is java.util.date.

  3. Monty | June 6th, 2009 at 7:28 pm

    Wow, java.util.Date still sucks? By all means go on a rampage to get the Apache or IBM java community to do something! Sun FAIL.