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

[Roger Riggs]

Hi Stephen,

Just to clarify, by non-offset based ZoneRules do you mean it has a 
fixed offset
meaning no transitions; aka ZoneRules.isFixedOffset() = true?

Thanks, Roger


On 4/24/2015 5:32 AM, Stephen Colebourne wrote:
> 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
>>>>>