JDK-8074023: Clock.system(ZoneId) could be optimized to always return the same clock for a given zone

Stephen Colebourne scolebourne at joda.org
Fri Apr 24 09:32:30 UTC 2015


The code in the webrev changes the behaviour of java.time, so cannot go in.

Run this code:
    TimeZone zone = TimeZone.getDefault();
    System.out.println(zone);
    ZoneId zoneId = ZoneId.systemDefault();
    System.out.println(zoneId);
    TimeZone.setDefault(TimeZone.getTimeZone("Europe/Paris"));
    TimeZone zone2 = TimeZone.getDefault();
    System.out.println(zone2);
    ZoneId zoneId2 = ZoneId.systemDefault();
    System.out.println(zoneId2);

before and after this change, a difference will be seen. Specifically,
ZoneId.systemDefault() responds to a change to TimeZone.setDefault().

The correct fix to this issue was outlined in the bug report.

1) 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.
2) Add a Clock instance variable to ZoneId that is only non-null if
the object is cached
3) Change Clock.system(ZoneId) to check to see if the clock in the
ZoneId is non-null before creating a new instance.

Stephen



On 23 April 2015 at 22:28, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi Peter,
>
> Setting the user.timezone property doesn't reset the value returned from
> getDefaultRef().
> You can see the new value through java.util.TimeZone but not through
> java.time.ZoneId.
>
> Its a bad idea to allow the default timezone change and in java.time it was
> purposefully
> handled as an initialize once value.
>
> Roger
>
>
>
> On 4/23/2015 5:20 PM, Peter Levart wrote:
>>
>>
>>
>> On 04/23/2015 10:33 PM, Roger Riggs wrote:
>>>
>>> Hi Peter,
>>>
>>> The defaultTimeZone is cached in java.util.TimeZone the first time it is
>>> referenced
>>> and is not updated after that.  See java.util.TimeZone.getDefaultRef().
>>>
>>> Regards, Roger
>>>
>>
>> But any code (with enough privilege) can update it:
>>
>> abstract public class TimeZone .... {
>>
>>     public static void setDefault(TimeZone zone)
>>     {
>>         SecurityManager sm = System.getSecurityManager();
>>         if (sm != null) {
>>             sm.checkPermission(new PropertyPermission
>>                                ("user.timezone", "write"));
>>         }
>>         defaultTimeZone = zone;
>>     }
>>
>>
>>
>> Peter
>>
>>>
>>> On 4/23/2015 4:11 PM, Peter Levart wrote:
>>>>
>>>>
>>>>
>>>> On 04/23/2015 09:53 PM, nadeesh tv wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Please review this minor change which  optimized
>>>>> Clock.systemDefaultZone() and Clock.system(ZoneId)  to avoid creating new
>>>>> instance of Clock.SystemClock every time they are called.
>>>>>
>>>>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8074023
>>>>>
>>>>> Webrev : http://cr.openjdk.java.net/~rriggs/nadeesh-tv-8074023/
>>>>>
>>>>
>>>> Hi Nadeesh,
>>>>
>>>> What happens if ZondeId.systemDefault() changes (TimeZone.setDefault())
>>>> *after* Clock class has already been initialized?
>>>>
>>>> Regards, Peter
>>>>
>>>
>>
>



More information about the core-libs-dev mailing list