Thursday 6 July 2006

A better datetime library JSR?

Do you hate the JDK Date and Calendar classes? Would you like to see an alternative in the JDK? Or are you happy with the JDK classes? Maybe you are happy with pulling in a jar file?

I ask because I get asked from time to time whether Joda-Time is going to get a JSR. Each time this comes up I point out that its a lot of work to do in my free time, and there are infrequent enough releases as is!

So, this blog is an open question - is it worth it? Should JDK7 contain a better datetime library? Please add a comment with your views, postive and negative so I can get some idea of peoples thoughts!

10 comments:

  1. Yes, you should do it, but not as a separate JSR... It should be part of JSR-275 Units Specification. Time is just another measurement, albeit a complex one.

    ReplyDelete
  2. i heard that was on the table before Tiger, but they did not do it due to the compatibility issues. i actually think it is time ot make a JDK with no deprecated methods, no stupid packges in it.. and i know that it is very hard to do..

    ReplyDelete
  3. I would really like to see this in the JDK, although I hope it wouldn't be too much of a time drain. Is there perhaps someone at Sun that could be the JSR spec lead with you as an advisor on the expert, as a workaround for your time constraints (no pun intended)?

    - Chris

    ReplyDelete
  4. Stephen Colebourne6 July 2006 at 13:28

    The link with JSR-275 could be tricky. They essentially have a completed model, which holds some time related concepts. But a datetime library is in fact something totally different.

    Interestingly, this could be an argument NOT to go the JSR route, as a nice datetime library could get ruined by being forced to be in line with other innapropriate specs.

    ReplyDelete
  5. Hi Stephen,

    The main question should be: what is the advantage of becoming a JSR? Everybody who is interested in Jodatime is able to get her hands on it, so I don't really see the need for the (apparently big) effort.

    ReplyDelete
  6. Christopher Brown8 July 2006 at 08:47

    The advantage of being in the JDK is that there can then be better integration with say MessageFormat or JDBC or lots of other APIs, instead of using wasteful conversion.

    - Chris

    ReplyDelete
  7. I am just waiting for it to be submitted... :-)

    ReplyDelete
  8. The main motivation for a JSR is exactly the integration with the rest of the core API. I don't think it is going to happen soon, though.

    Besides, a JSR threatens to deface the libarary: look what they've done to Doug Lea's util.concurrent package -- and he was on the spec group!

    ReplyDelete
  9. I'm against including Joda-Time in the JDK simply because that would mean updates take forever. Now what would be helpful is a set of interfaces that allow Joda-Time, JDK, and other libraries to interoperate.

    Off topic, in reply to Tiago: What bad thing happened to the the concurrent package? It seems to me much better than the EDU.oswego stuff.

    ReplyDelete
  10. My main complaint is: where's the Synch interface? I like to mock stuff and switch implementations around when I'm unit testing. I also miss the simplicity of the WaitableXXX classes.

    About interoperation between libraries: Joda is becoming the de facto standard for time, from where I look. If this really happens, integration will come on its own. This is much better than a comitee.

    ReplyDelete

Please be aware that by commenting you provide consent to associate your selected profile with your comment. Long comments or those with excessive links may be deleted by Blogger (not me!). All spam will be deleted.