JDK-8142508 : To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-11-11
  • Updated: 2017-10-16
  • Resolved: 2015-12-08
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.
9 b97Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8175192 :  
The current j.u.z.ZipFile has following major issues:

(1) Its ZIP file format support code is in native C code (shared with the VM via ZipFile.c -> zip_util.c). Any entry lookup, creation requires multiple round-trip of expensive jni invocations.

(2) The current native C implementation code uses mmap to map in the central directory table appears to be a big risk of vm crash when the underlying jar file gets overwritten with new contents while it is still being used by other ZipFile.

(3) The use of "filename + lastModified()" cache (at native) appears to be broken if the timestamp is in low resolution,and/or the file is being overwritten.

The clean solution here is to bring the ZIP format support code from native to Java to remove the jni invocation cost and the mmap risk. Also to use the fileKey and lastModified from java.nio.file.attribute.BasicFileAttributes to have better cache matching key.
The changeset for this rfe had been backout for 8144958. The updated change will be integrated via jdk-8145260