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!

6 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