RFR: JDK-8074002 java.time.ZoneId.systemDefault() should be faster

[Peter Levart]

On 05/06/2015 04:11 PM, Roger Riggs wrote:
> Hi Peter,
>
> Yes, looks good.
>
> Roger 

On 05/06/2015 02:44 PM, Daniel Fuchs wrote:
> Hi Peter,
>
> The logic looks good to me.
> But I'm not an expert of the field, despite my small incursions :-)
>
> I wish we didn't have to do defensive cloning - but I don't see
> any way around.
>
>
> best regards,
>
> -- daniel

Hi Roger, Daniel, Stephen,

Thanks for reviewing. Defensive cloning is a good thing. In particular 
here. TimeZone is a mutable object and not thread-safe. So the 
expectation is that only a single thread accesses a particular object. 
TimeZone.getDefault() already did cloning, now setDefault() also does 
the same so that no sharing can occur among threads. Any potential code 
that called setDefault(tz) and then later changed the ID of passed-in tz 
object was broken anyway, just waiting for data-race to occur.

Regards, Peter

>
> On 27/04/15 17:26, Peter Levart wrote:
>> Hi,
>>
>> Please review the following improvement that caches default ZoneId
>> object and makes the frequently executed ZoneId.systemDefault() method
>> faster:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.04/ 
>>
>>
>>
>> The patch is just a rebased version of webrev.03 + some comments added
>> about the importance of defensive cloning in TimeZone.setDefault().
>> There was already a discussion about this patch a while ago and Stephen
>> basically approved it in this form:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031714.html 
>>
>>
>>
>>
>> Thanks,
>>
>> Peter Levart
>