Monday, 10 February 2014

New project: ThreeTen-Extra for JDK 8

JDK 8 includes JSR-310, a new date and time library. But what about functionality that didn't make it into the JDK?

ThreeTen-Extra

The main ThreeTen project is now essentially complete. The project was developed and delivered via JSR-310 into OpenJDK and JDK 8.

However, as part of that process, certain pieces of functionality were rejected and/or excluded from the JDK. This was sometimes due to scope management and sometimes due to whether something was appropriate for the JDK.

The TheeTen-Extra project provides a home for that functionality.

ThreeTen-Extra is a project on GitHub that provides additional functionality. It is delivered via Maven Central and is dependent on JDK 8.

The following functionality is currently provided:

  • DayOfMonth temporal value type
  • DayOfYear temporal value type
  • AmPm temporal enum
  • Quarter temporal enum
  • YearQuarter temporal value type
  • Days, Months and Years amount value types
  • Next/previous day adjusters that skip the weekend (Saturday/Sunday)
  • Coptic calendar system
  • Support for the TAI and UTC time-scales

The project has spare space to add more functionality, so long as it is generally applicable. For example, additional calendar systems would be a good fit. Feel free to raise a pull request with your ideas.

Summary

The ThreeTen-Extra project is now available, providing an additional jar file of date/time code that builds on java.time (JSR-310) in JDK 8.

Comments welcome!

13 comments:

  1. A weekend isn't always Saturday/Sunday.

    In Israel it is Friday/Saturday and Sunday is the first working day for example.

    ReplyDelete
    Replies
    1. Agreed. But providing a Sat/Sun method is a reasonable place to start...

      Delete
  2. Why JDK 8 doesn't have so common classes, for example: Days, Months, Years? Why did they rejected or excluded?

    ReplyDelete
    Replies
    1. JDK 8 has the Period class, which can store an amount in days, months and years. There is less need for a class that can only store months.

      Delete
    2. Stephen Colebourne, could you answer me? Did you reject Days, Months, Years utilities classes? Or other members of JSR was done this.

      Delete
    3. The classes were removed years ago as they turned out to be an impractical design for the API given the limitations of the Java language. I made the removal and still agree with it. The JDK does not need those three classes (as it has the Period class instead), but they are useful for an external library.

      Delete
  3. Any chance something like TAI / GPS will make it into future versions of JSR-310?

    ReplyDelete
    Replies
    1. I think Oracle would have to be pushed by a big paying customer for that to happen at this point. They want to keep the date/time API of a reasonable size and see TAI/UTC as non core.

      Delete
  4. Hi Stephen, I'm glad to see this new date/time model in Java. Have you read the paper "A point based model of the Gregorian Calendar" ? http://www.sciencedirect.com/science/article/pii/S1477842405000424
    It has the same abstractions that you propose and more, like TimeLineFilter, relative dates, etc. It is implemented in Smalltalk as open source project called Chalten (http://smalltalkhub.com/#!/~HernanWilkinson/Chalten) and supports other calendars as well and it is based on a measure model that allows you to represent any type of time measure like 10 days, 3 weeks or 100 years, etc.
    If you want the paper let me know, I was one of the authors :-)

    ReplyDelete
    Replies
    1. Thanks for the links. I haven't read the paper. Perhaps you could send a copy? scolebourne/joda/org

      Delete
  5. Is there an extra-package that can be used with threetenbp 1.0 for Java 6?

    ReplyDelete
    Replies
    1. The project is here https://github.com/ThreeTen/threetenbp-extra however it is out of date and has not had any releases.

      Delete
    2. Thank you for this, but unfortunately it won't compile with threeten 1.0 and Java 6. So no extras for me, unfortunately.

      Delete