RFR: 8222440: (zipfs) JarFileSystem does not correctly handle versioned entries if no root entry is present

[Langer, Christoph]

Hi,

please review a fix for an issue with zipfs/jarfs regarding multi-release jars.

The issue is observed when an mr-jar does have entries for certain files in the versioned subfolders but not in the main tree. This should be allowed as per JEP 238 [0]. So, say, if a jar file contains an entry '/META-INF/versions/11/file.txt' but not the entry 'file.txt', this will not correctly be visible when walking the jar file with jarfs. I discovered this when working on JDK-8222276 and saw a suspicious usage of IndexNode.keyOf() to create a virtual index node for the JarFileSystem lookup table. So I enhanced the test 'test/jdk/jdk/nio/zipfs/jarfs/JFSTester.java' to demonstrate the issue. The updated test case will fail with the current coding and works with the proposed fix.

Here are some details:
JarFileSystem builds a lookup table to return for any jar entry its versioned entry, should it exist, in favor of the standard root entry. This is done by overriding ZipFileSystem's getInode() method and using a lookup table to return the correct versioned entry. The actual root inode is the key of this lookup table, which requires that it exists. If there is no root inode in the jar, there is code to create a virtual inode. But as it is right now, this does not work because a special singleton key node is used as virtual node which constantly changes its name. Furthermore, the node is not added to the jar file system node hierarchy. I enhanced this by correctly creating a 'virtual' root inode, making sure all parent directory inodes exist and if not creating and adding them into the jarfs/zipfs hierarchy to allow for iterating subdirectories.

I also enhanced 'test/jdk/jdk/nio/zipfs/jarfs/JFSTester.java' to demonstrate the issue. The test furthermore does not rely on files that are checked in in the source tree any longer but creates the test.jar by means of JarBuilder. I also don't delete test.jar in the test but leave it to jtreg to delete the scratch directory. That helps when analyzing test issues where scratch directory contents shall be retained.

Bug: https://bugs.openjdk.java.net/browse/JDK-8222440
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222440.0/

Thanks in advance
Christoph

[0] https://openjdk.java.net/jeps/238