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
