JDK-8074023 : Clock.system(ZoneId) could be optimized to always return the same clock for a given zone.
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.time
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-02-27
  • Updated: 2018-09-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8073394 - Clock.systemUTC() should return a constant
Relates :  
JDK-8074002 - java.time.ZoneId.systemDefault() should be faster
Description
Clock.systemUTC() has been optimized to return a constant.
It would be good if Clock.systemDefaultZone() and Clock.system(ZoneId) could also be optimized to avoid creating new instance of Clock.SystemClock every time they are called.

One possible solution was proposed on core-libs-dev:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031759.html
Comments
Checking the code, it turns out that for ZoneRegion (one subclass of ZoneId), a new ZoneId instance is created every time ZoneId.of() is called. The underlying ZoneRules are cached, but not the ZoneId. For ZoneOffset (the other subclass of ZoneId), caching occurs for offsets that are 15mins apart (a sensible balance of memory usage). It would seem reasonable to add caching for those ZoneRegion instances that have a non-offset based underlying ZoneRules. This would be done in ZoneRegion.ofId(). Those instances of ZoneRegion created by ZoneId.ofOffset() would not be cached. With caching of a sensible selection of both ZoneOffset and ZoneRegion, the issue referred to here could then be tackled. The cache within ZoneId would probably be lazy rather than eager.
27-02-2015