• Type: JEP
    • Status: Closed
    • Priority: P4
    • Resolution: Delivered
    • Fix Version/s: 8
    • Component/s: core-libs
    • Labels:
    • Author:
      Stephen Colebourne
    • JEP Type:
    • Exposure:
    • Scope:
    • JSR:
    • Discussion:
      core dash libs dash dev at openjdk dot java dot net
    • Effort:
    • Duration:
    • JEP Number:



      Define a new date, time, and calendar API for the Java SE platform.


      • Support standard time concepts including date, time, instant, and time-zone
      • Immutable implementations
      • Provide an effective API suitable for the JDK, focussed on developer usability
      • Integrate with existing JDK APIs
      • Provide a limited set of calendar systems and be extensible to others
      • Use relevant standards, including ISO-8601, CLDR, and BCP47
      • Be based on an explicit time-scale with a connection to UTC


      It is not a goal to solve all date/time problems, but the new API should be a suitable base for external extensions.


      The existing Java date and time classes are poor, mutable, and have unpredictable performance. There has been a long-standing desire for a better date and time API based on the Joda-Time project. The new API will have a more intuitive design allowing code to better express its intent. The classes will also be immutable which aligns with the multi-core direction of the industry.


      The JSR 310 EG has been working on a new date/time API for Java platform. The goal of this project is to integrate the JSR 310 reference implementation into JDK 8.

      Integration will involve successfully working with any new module system. There may be a need to provide for core embedded and mobile module with a subset of functionality.

      The project will also require the JSR 310 classes to be integrated with existing classes. For example, there should be only one source of time-zone data in the JDK. It is also intended that the existing formatters will support the new classes.


      No specific requests beyond the normal unit/regression test development. JSR 310 has already developed a large test suite, which is being divided into TCK and non-TCK tests.

      Risks and Assumptions

      The project is primarily implemented by non-Oracle personnel who are not funded to work full-time on this project.

      A review of immutability and thread-safety will be necessary and is assumed.


      • There are no current dependencies on Project Lambda, however that may change during integration.

      • The module system design for the whole JDK will affect the design of JSR 310.


      • Other JDK components: Other APIs should be reviewed to see if they could utilise JSR 310 classes

      • Compatibility: New code and some new methods on existing classes

      • Security: None expected

      • I18n/L10n: Might need additional i18n framework to better support non-Gregorian calendars

      • Portability: The basic work requires no additional native code, however a more precise system clock would be desirable

      • Documentation: Standard javadoc & examples, probably updates to the tutorial/guides

      • TCK: New JCK test development

      • Legal: Integration of BSD 3-clause licensed code from JSR 310

        Issue Links


          There are no comments yet on this issue.


            • Assignee:
              sherman Xueming Shen
              scolebourne Stephen Colebourne
              Xueming Shen
              Endorsed By:
              Brian Goetz
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: