Michael Nascimento Santos's Blog

Tiger and dates don't get along

Since Java WebStart 1.4 does not work on Linux kernel 2.6, there are many new features in a certain operating system release that are interesting to the customer I am currently working for and some applications they are willing to use require Java 5, we have started testing their main application on Tiger. However, it fails miserably due to two major bugs that have been available since the first day Java 5 was released.

First, TimeZone.setDefault(TimeZone) is severely broken. Instead of setting the JVM-wide TimeZone default instance, it now works on a thread-basis!. Ok, to be more precise, it uses a InheritableThreadLocal, which means you will have to set the TimeZone instance for all "parent" threads in your application. If you are developing a desktop application and setting the default TimeZone from the main thread before the GUI starts, all code that runs from the event dispatch thread won't see your changes! This bug has been reported and the submitter even suggested a workaround for the event dispatch thread, but the fix will only be available on Update 7!

Then, there is a binary compatibility bug since the first Java 5 release: java.sql.Timestamp.compareTo(java.util.Date) now throws a ClassCastException. If you declared all your references as Dates and used Hibernate, for instance, to initialize them, it is pretty hard to isolate these problems. It gets a lot worse if you have used Collections.sort(..) or Collections.max(..) in your code, since it gets impossible to detect this. This bug has been reported nearly one year and a half ago and has only been fixed last month. However, the fix will only be available in Update 7, whenever it is available.

So, if you deal with Date, Calendar or use Timestamp comparissons in your JDK 1.4 compatible system or even plan to do so in Tiger, hold your breath: wait for Update 7, whenever it comes around. If you have to upgrade to Java 5 by a certain date due to other reasons, you are in big trouble, just like me. Notice I didn't even mention all the daylight saving problems you will have to cope with if you are just interested in dealing with "plain" dates...

Unfortunately, the best advice I can give to anyone planning to do even some simple work with dates is to use Joda-Time, a great piece of Apache-licensed open-source software created by Stephen Colebourne.

As a JCP member, I have to ask: which companies or individuals is willing to support a JSR to add a Joda-Time based API to Dolphin and solve this mess in a proper manner?

Comments

• I would certainly hope to see Joda-Time included as standard. The idea certainly seems to have a few supporters judging by various threads on this subject in various places. Most arguments against Joda-Time are based on footprint, yet it includes extra capabilities and calendars.

  Furthermore, it's obliged to include data (calendars, timezones and the like) with extra information that already exists partially in the resources of the current JDK. If Joda-Time were included, then you could throw out the old resources and have Date and Calendar map onto Joda's resources, reducing the overall footprint (as you could eliminate the duplication).

  Date and Calendar are bad APIs with well-known deficiencies (just read "Effective Java" by Joshua Bloch to get an idea if it isn't already obvious). OK, there would then be three APIs, but at least one of them would be good...

  - Chris

  Posted by: chris_e_brown on February 08, 2006 at 01:30 PM

• Hi Chris,

  If we should be concerned about footprint then many APIs added to Mustang should be removed. And I do believe Joda-Time capabilities matter to more developers than some of these APIs. So, footprint should not prevent us of adding a Joda-Time-like API to the core.

  I do believe Date and Calendar should be reworked to delegate to this new API and that many methods in the JDK should be deprecated and replaced by new ones that use the "correct" APIs.

  It is high time the JDK shipped with a working Date API. So, I am really looking for supporters.

  Posted by: mister__m on February 09, 2006 at 04:46 AM

• Hi Michael, what sort of support are you looking for? What does it involve? In any case, I fully agree with you here.-Chris

  Posted by: chris_e_brown on February 09, 2006 at 05:27 AM

• > I would certainly hope to see Joda-Time included as standard.

  +1 to that.

  Posted by: inadarei on February 09, 2006 at 07:51 AM

• Joda time is an excellent piece of software and I wish that functionality was in the standard JDK. However do you know that the jar is 520k (half a megabyte) even when it is compressed!

  You can never replace Calendar and Date with the Joda time equivalents since that would kill a lot of applications that has actually been written to cope with Calendars oddities.

  I think we need a Java plugin framework for this to be a viable option. Which means you only need to download/install Joda if you use an application that needs it. This should be automagic though. Unfortunately I am very pessimistic that a plugin framework will ever happen for Java...

  Cheers,
  Mikael Grev

  Posted by: mgrev on February 09, 2006 at 08:30 AM

• Mikael,
  I don't think there's any suggestion of dropping Date or Calendar, as (for the reasons you mentioned) that'd break a huge number of applications. And as I suggested, a large part of Joda-Time's JAR file is made up time zone resources that are a superset of information already in the JDK. By adding Joda-Time, you could delete the equivalent resources in the JDK and change the internals of Date and Calendar to use the relevant subset of Joda-Time's resources.
  And if you don't want extra features and a bigger download, you don't need to download it, just use an older, smaller JDK.
  I'm not sure a plug-in framework would work, as large IT departments might not want all the extra traffic as parts are downloaded. That would also open the door to lots of extra combinations of configurations and be a testing nightmare (which version of which plugin is available on which desktop?) and would cause major pauses in applications as they downloaded dependencies, adding to the perception that Java is slow.
  - Chris

  Posted by: chris_e_brown on February 09, 2006 at 08:38 AM

• I forgot to add that I'm not one for recommending adding APIs to the JDK for convenience. In this case though, it'd be worth it, through the extra capabilities (performance and reliability through immutability, extensibility) of Joda-Time and simply because Date is a bottleneck and bad design, and Calendar is not much better.

  If it's design choices for Java 7 we're discussing here, I'd far rather have Joda-Time than some awful syntax for adding XML support at language level. Leave that to Rhino, Groovy, and company...

  - Chris

  Posted by: chris_e_brown on February 09, 2006 at 08:42 AM

• Hi Chris,

  By support I mean: if you are a JCP member, please send me a private message so we can start to persuade some important community members to submit a joint JSR.

  Regards,
  Michael

  Posted by: mister__m on February 09, 2006 at 08:44 AM

• Hi Mikael,

  You said:

  Joda time is an excellent piece of software and I wish that functionality was in the standard JDK. However do you know that the jar is 520k (half a megabyte) even when it is compressed!

  Hmm, do you know how big the all the webservices & XML APIs added to Mustang are? You'd cry then :-) So, size is no issue, because if it was, we'd better remove half of Mustang features before it ships.

  You can never replace Calendar and Date with the Joda time equivalents since that would kill a lot of applications that has actually been written to cope with Calendars oddities.

  They wouldn't be replaced, but rather deprecated and rewritten to use the new API.

  I think we need a Java plugin framework for this to be a viable option.

  Yes, we do, but this is a totally unrelated issue, since it affects the whole JDK infrastructure.

  Regards,
  Michael

  Posted by: mister__m on February 09, 2006 at 09:15 AM

• The webstart bug is not related to the Linux Kernel release; it's actually related to the glibc release (Glibc is the run-time library most Linux apps use, like MVCRT.DLL or VBRUN.DLL for Windows). And it was a bug from JWS itself, who sent the wrong paramters to the C function. The bug also affected 1.4.2 and the bug page states is is fixed by now.

  Posted by: flozano on February 09, 2006 at 10:04 AM

• The webstart bug is not related to the Linux Kernel release; it's actually related to the glibc release

  Yes, I know that, but as far as I can tell from my limited Linux knowledge, getting kernel 2.6 to use a previous glibc release is a lot of work and is simply not a solution for those running webstart applications.

  And it was a bug from JWS itself, who sent the wrong paramters to the C function.

  Yes, you are right.

  The bug also affected 1.4.2 and the bug page states is is fixed by now.

  Fixed in 5 and 6, which is irrelevant for those using 1.4.x.

  Posted by: mister__m on February 09, 2006 at 10:14 AM

• i dsagree that Joda should be part of JDK. Also extra calendars should not be a part of the JDK. a calendar pack can be presented seperately. Although JODA time is very good, it is unfortunately bloated, and for many applications avantages simply does not justify the shortcomings of the JDK. instead, bugs in the JDK an be fixed and people can use JODA if they want.
  Or, if Sun decides to shake the whole JDK, the API can be redesigned using the JODA, eliminating all the unnecssary packages, deprecated methods etc while providing a back compatibility package. but this will not likely to happen.

  Posted by: ahmetaa on February 09, 2006 at 12:26 PM

• the Dates/Calendar APIs will never really be fixed - mainly due to 'compatibility' reasons. Instead bugs get classified as RFEs (e.g. #4995685).
  So, the only option seems to add another API in parallel...
  

  Posted by: nalte on February 09, 2006 at 12:54 PM

• thank you mister_m for writing about this. I experienced similar issues when working with Tiger. Since my application didn't need Tiger I just switched back to 1.4 after frustration. I vote to just create a simple and intuitive Date/Time class in parallel. I haven't looked at Joda-Time but will now! Thanks to all for the discussion.

  Posted by: brl4n on February 09, 2006 at 02:11 PM

• Thanks for the feedback on Joda-Time. I always find the 'bloated argument interesting. For the record, here are two relevant points:

  1) I expect to be breaking out the 'unusual' calendars from Joda-Time fairly shortly, so most users won't need that jar file.

  2) About 40% of the Joda-Time jar file size is time-zone data, which would not be duplicated if Joda-Time joins the JDK.

  The full analysis by Brian O'Neill from June 2005 is copied from our list here:

  Some people have complained that the Joda-Time jar file is too large. I decided to do some size comparisons. Note: 1k = 1024 bytes.

  The current size of the jar file for 1.1 is 496k. When the three obsolete solar8x time zones are removed, the size is 489k. When all the time zones are removed, the size is 352k. When the license and notice text files are removed, the size is 348k. By the way, I recommend we chuck the obsolete zones.

  For comparison, I extracted all the files from JDK1.5 supporting dates. This includes not only classes, but time zone data files. I did not consider the files needed for date format localization, since Joda needs these too. The classes came from java.text, java.util, sun.util, and sun.util.calendar. A jar of just the classes is 83k. When time zone data is added (excluding the solar8x zones), the jar file is 288k. Including these zones it is 300k.

  Comparing the code and data (including the obsolete zones) Joda-Time is about 65% larger. Even though Joda-Time has much more code, it stores time zone data more efficiently. Joda-Time needs 144k, but the JDK needs 217k.

  The JDK doesn't actually store the time zone data files in the rt.jar file. It stores them in separate files in the jre/lib/zi directory. Since almost all file systems consume one sector for even the smallest file, the actual amount of space consumed on the disk is much larger. On my machine the sectors are 4k, and the space consumed by the zi directory is 1644k.

  Comparing Joda-Time vs the JDK on disk space consumed, the JDK is 248% larger, or 3.48 times the size. Of course, this varies per file system.

  If Joda-Time was included in the JDK and replaced the bulk of the current implementation, the JDK distribution would grow by a small amount, but the disk space consumed would shrink.
  

  Posted by: scolebourne on February 09, 2006 at 04:55 PM

• thanks for the explanation 'scolebourne '.

  one funny thing about the name "Joda":
  http://en.wiktionary.org/wiki/joder

  Posted by: ahmetaa on February 09, 2006 at 05:53 PM

• Thanks to Stephen Colebourne for the detailed discussion of the "bloat" argument (I didn't have any figures, but I suspected that the JAR would be able to be integrated into the JDK with very little impact given the duplication of data).

  As a parallel, Doug Lea's util.concurrent was brought into the JDK despite existing as a pure Java separate download beforehand (just like Joda-Time at present). Integrating into the JDK didn't add many extra capabilities (all though there were some enhancements brought about through integration), but it certainly proved to be more usable and powerful than simple synchronized and Object.wait() constructs. I believe that Joda-Time is also as worthy for inclusion as it's so fundamental. We're not talking about non-critical lightweight options such as Swing/AWT layout managers.

  - Chris

  Posted by: chris_e_brown on February 09, 2006 at 11:37 PM

• To any JCP member reading this, please send me an email if you'd like to support a JSR to solve this problem.

  Posted by: mister__m on February 10, 2006 at 04:00 AM

• I don't think your example of the TimeZone bug is correct.

  If you set the default tz in main, then start the gui, the gui does get the correct default.

  The problem is that if you set the default tz in another thread (eg awt ed thread) and then expect it to be there in main.

  Also, looking at bug parade, it seems this was only fixed in mustang (b53); are you sure it's fixed in update 7 of tiger?

  Posted by: goron on February 21, 2006 at 09:14 AM

• Hi goron

  I don't think your example of the TimeZone bug is correct.
  If you set the default tz in main, then start the gui, the gui does get the correct default.

  Not in a webstart application. The EDT is started by the console before the application is started, therefore changing behaviour.

  Also, looking at bug parade, it seems this was only fixed in mustang (b53); are you sure it's fixed in update 7 of tiger?

  Yes, I am sure. It explicitly says: "This incompatible behavior has been fixed in Mustang b53 and 5.0u7 b01".

  Posted by: mister__m on February 21, 2006 at 11:26 AM

This work is licensed under a Creative Commons License.