java.time.ZoneId.systemDefalut() overhead

[Claes Redestad]

On 2015-02-23 22:58, Peter Levart wrote:
>
> On 02/23/2015 10:55 PM, Xueming Shen wrote:
>>> If we're talking about using java.time from ZipEntry, then that's 
>>> another story. I belive that VM startup does not need the conversion 
>>> from DOS time to Java time in ZipEntry, but that should be checked 
>>> to be sure...
>>
>> I was talking about to use j.time for the dos<-> conversion, I would 
>> assume that
>> was the original optimization you were talking about. With Claes's 
>> change, it is
>> possible the j.u.zip code no longer needs to the dos->java time 
>> conversion during
>> startup.  The dos timestamp in Zip spec is indeed a 
>> j.time.LocalDateTime.
>
> You're right. I'm thinking of new proposed code which does lazy DOS -> 
> Java conversion. Previously (or currently, to be precise), 
> constructing ZipEntry already triggered conversion.
>
> Peter
>

Testing using both a "Hello world"-style application and some slightly 
more realistic applications, I can verify that the j.u.zip.ZipUtils 
class does not get loaded during VM startup with my patch for 8073497 
applied. Further applying Peter's patch to cache ZoneId's in 
j.u.TimeZone on top of that does not add any java.time classes, even 
when java.util.TimeZone is loaded (the new 
sun.misc.JavaUtilTimeZoneAccess class gets loaded in these scenarios, 
though).

/Claes