Using Agile in less-than-perfect situations since Y2K
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
Calendarrepresents a time after the time represented by the specified
Object… if and only if
Calendarinstance. Otherwise, the method returns
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
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,
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.