JEP 150: Date & Time API
|Discussion||core dash libs dash dev at openjdk dot java dot net|
|Endorsed by||Brian Goetz|
|Blocks||JEP 170: JDBC 4.2|
|Duplicates||JEP 151: Compress Time-Zone Data|
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.
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