Hi Christoph, Overall, I think the changes look good.
Was there a reason that you did not leave the multi-release 9 test as is when you added the 10 test? As far as removing the jar file, I would think that would still want to be done. I understand why you did this, not sure what the standard is here as most tests try to do clean up Best Lance > On Apr 16, 2019, at 4:50 PM, Langer, Christoph <christoph.lan...@sap.com> > wrote: > > 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 > <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
