JDK-8073497 : Lazy conversion of ZipEntry time
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-02-19
  • Updated: 2016-05-27
  • Resolved: 2015-02-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u60Fixed 9 b54Fixed
Related Reports
Relates :  
JDK-8066644 - Fix deprecation warnings in jdk.zipfs module
Relates :  
JDK-8130914 - java/util/zip/TestExtraTime.java fails with "java.lang.RuntimeException: setTime should make getLastModifiedTime return the specified instant: 3078282244456 got: 3078282244455"
Relates :  
JDK-4981560 - ZipEntry.dosToJavaTime() uses deprecated (and thread-blocking) Date constructor
Relates :  
JDK-8055854 - Examine overhead in java.net.URLClassLoader
Description
When reading java.util.zip.ZipEntry:s from a zip archive, java.util.zip.ZipUtils.dosToJavaTime is called eagerly.

This forces initialization of deprecated java.util.Date utilities early in the startup to evaluate values. 

In practice the VM typically never look at the ZipEntry.getTime(). Preliminary testing shows this can have a positive impact on startup and VM footprint.
Comments
The time field and its conversion was lazy pre-8-b94, where it was removed in favor of the FileTime fields, then the ZipEntry.time field was reintroduced but in the current, eager fashion. I think it's thus safe to consider the current behavior a regression due to the sum of these changes.
21-02-2015