java.time.ZoneId.systemDefalut() overhead
Claes Redestad
claes.redestad at oracle.com
Mon Feb 23 23:15:18 UTC 2015
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
More information about the core-libs-dev
mailing list