Summary

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

Goals

• Support standard time concepts including date, time, instant, andtime-zone
• Immutable implementations
• Provide an effective API suitable for the JDK, focussed on developerusability
• 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

Non-Goals

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

Motivation

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

Description

TheJSR 310 EG has been working on a new date/time API for Javaplatform. The goal of this project is to integrate theJSR 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 asubset of functionality.

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

Testing

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

Risks and Assumptions

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

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

Dependences

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

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

Impact

• Other JDK components: Other APIs should be reviewed to see if theycould 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 supportnon-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 thetutorial/guides

• TCK: New JCK test development

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