On 02/27/2015 12:10 AM, Peter Levart wrote:
On 02/26/2015 11:47 PM, Stephen Colebourne wrote:
Personally, I found the SharedSecrets version easier to follow. I also
suspect that the toZoneId0() method would be invoked most of the time
with this variant, resulting in no beneficial inlining effect.
Not true. Once the toZoneId0() invokes baseZone.toZoneId() (on the
base instance which is attached to defaultTimeZone static field) the
ZoneId object will be set on both instances (base and clone). Next
call to TimeZone.getDefault() will create another clone of default
TimeZone, but this time, the cloned zoneId field will already point to
cached ZoneId. That and EA-based elimination of clone's allocation
makes this variant as performant as SharedSecrets based.
But I agree that it is not simple to follow all the possible code
paths. The benefit is that java.time is not dependent on ShareSecrets.
Here's another variant that doesn't use a back link to base TimeZone:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.03/
I think it's easier to follow than previous one.
Regards, Peter
