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

Peter Levart peter.levart at gmail.com
Wed May 6 15:38:45 UTC 2015

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

More information about the core-libs-dev mailing list