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.ri...@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
>>>>
>>>
>>
>
