RFR: 8073394: Clock.systemUTC() should return a constant

[Peter Levart]

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.levart at 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
>>
>