RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start
Jaikiran Pai
jai.forums2013 at gmail.com
Sat Feb 1 07:38:42 UTC 2020
Can I please get a review and a sponsor for a patch for
https://bugs.openjdk.java.net/browse/JDK-8211917?
The webrev containing the patch is available at
https://cr.openjdk.java.net/~jpai/webrev/8211917/1/webrev/
The commit in the patch updates the jdk.nio.zipfs.ZipFileSystem to write
out the manifest (if any) as the first entry in the LOC. That then
allows the java.util.jar.JarInputStream to find the manifest and return
it through JarInputStream.getManifest().
In an initial attempt at this patch, I had tried to just reorder the CEN
to add the manifest entry first instead of forcing the manifest entry
first in the LOC. But that didn't work and the JarInputStream still
couldn't find the manifest. So I used this approach to force the
manifest as the first entry in the LOC (and the existing code
effectively also ensures that it's also the first entry in the CEN).
The patch also includes a test case to reproduce this issue and verify
the change. In the test case I intentionally used the verbose version of
the FileSystem.newFileSystem() API, instead of the newer simpler ones.
This is to allow cleaner/easier backporting of this patch to Java
version 8 if and when that happens. Functionally, which API variant of
the FileSystem.newFileSystem() API is used shouldn't matter in the
context of this test case. However, if someone feels that I should
switch to the newer available API, then please do let me know and I'll
update the patch.
-Jaikiran
More information about the nio-dev
mailing list