On 02/24/2015 11:16 AM, Daniel Fuchs wrote:
Hi Peter,
On 24/02/15 10:00, Stephen Colebourne wrote:
On 23 February 2015 at 22:27, Peter Levart <peter.lev...@gmail.com>
wrote:
What about the following idea:
- create a (maybe still package-private) instance method
ZoneId.getSystemClock() and cache the per-ZoneId Clock instance
inside the
ZoneId.
- Clock.system(ZoneId) static method is then just delegating to
ZoneId.getSystemClock().
- Similarly Clock.systemDefaultZone() can just return
ZoneId.defaultSystem().getSystemClock().
- Similarly Clock.systemUTC() can just return
ZoneOffset.UTC.getSystemClock().
Or do we just want to cache systemUTC() Clock here?
I suspect that the above would be a good optimisation, though perhaps
a separate issue?
I agree with Stephen here.
There is an immediate value in having Clock.systemUTC() always
return the same clock.
I believe it could also be good for Clock.systemDefaultZone() to
always return the same clock as long as the default zone doesn't
change - and what you are proposing would solve this issue.
It was bothering me that Clock.systemUTC() could be optimized
but Clock.systemDefaultZone() could not.
But I'd rather handle that in a separate issue.
I'd like to understand all the implications of having
ZoneId depend on Clock, and whether it's worth it to
have an additional Clock field in all instances of ZoneId.
best regards,
-- daniel
Yes, I had that concern too. Too much caching where you don't need it
can be contra-productive.
Regards, Peter
Stephen
