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

[Roger Riggs]

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
>>>
>>
>