Java's Little Gems

In my current project there were some tests failing on and off. We were getting used to that fact and just ignored even though our continuous integration build didn't like it that much.

In general I hate such situation and I would have looked into that but unfortunately I did not find time to do so. Well, now as the project comes to an end for me I finally stumbled over the culprit just by chance. It turned out that the error came from overly complicated code and compared with some Java shortcomings were responsible for the error.

The author or that particular method had the task to compare two date objects if they are of the same day (disregarding fractions of a day). In Oracle that is call truncating a date. There he implemented a truncateDate method taking a date as argument:

1. Created a Calendar instance
2. Set the Time using the given Date
3. Obtaining the Year, Month and Day of Month number
4. Creating a new Date using the given Year, Month and Day of Month obtained in 3)
5. Return the date's time in milliseconds using Date.getTime() method

Now in Java that can fail because the Date object's time may vary even when created with the same time in milliseconds. This means that this might be true or might be false:

long ts = 1234567890;
new Date( ts ).getTime() == new Date( ts ).getTime()

Isn't that funny. I discovered that when trying to convert Dates back and forth over JSon. This also means that the a comparison of the two truncated dates with the method above might or might not return the same long value. To fix it I retired the truncateDate method and created a compareTruncatedDate method which compares the dates using theirs Year, Month and Day of Year value. Now the tests are returning the same results over and over again.

Have fun - Andy