-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
None
-
None
My colleague Shai Barack noticed the following enhancement opportunity:
java.util.zip.ZipFile currently reads the central directory into a byte[]: https://github.com/openjdk/jdk/blob/a606836a02bb3e4ff3e3aaad478fc7ac142b3e38/src/java.base/share/classes/java/util/zip/ZipFile.java#L877C49-L877C60
Using mmap instead would avoid the copy, and improve performance of ZipFile.
Earlier JDK versions did use mmap, but that was removed inJDK-8145260 'to remove the expensive jni cost and mmap crash risk'. Today, the mmap could be done using FileChannel, which would avoid the jni cost. The 'mmap crash risk' could still exist, so the compatibility impact would have to be weighed.
I think the crash risk refers to the possibility that the zip file could be modified in-place while it is being read, and after it has been mapped. There were some examples of this happening (JDK-8152661, JDK-8031691). A comment in JDK-8152661 mentions this is unsupported and suggests changing application code to not do that, which I agree with.
java.util.zip.ZipFile currently reads the central directory into a byte[]: https://github.com/openjdk/jdk/blob/a606836a02bb3e4ff3e3aaad478fc7ac142b3e38/src/java.base/share/classes/java/util/zip/ZipFile.java#L877C49-L877C60
Using mmap instead would avoid the copy, and improve performance of ZipFile.
Earlier JDK versions did use mmap, but that was removed in
I think the crash risk refers to the possibility that the zip file could be modified in-place while it is being read, and after it has been mapped. There were some examples of this happening (
- relates to
-
JDK-8145260 To bring j.u.z.ZipFile's native implementation to Java to remove the expensive jni cost and mmap crash risk [2]
- Resolved