RFR: 8222440: (zipfs) JarFileSystem does not correctly handle versioned entries if no root entry is present
christoph.langer at sap.com
Tue Apr 23 09:37:25 UTC 2019
> Overall, I think the changes look good.
Thanks for looking at this.
> Was there a reason that you did not leave the multi-release 9 test as is when
> you added the 10 test?
Well, since I wanted to use this test as blueprint to provoke the jarfs issue, I had a closer look to it. I thought it's nicer if the structure of the jar file to test could be defined in the code rather than by directory trees checked into mercurial. But if you think, it's not a good idea to refacture this, I can also leave it untouched. I could alternatively add my test as a net new testcase.
I also thought already, that I'd hereby remove a test path for the jar tool to create multi release jars... wanted to check if that's tested somewhere else still.
So what do you (or others) say which way I should go?
> 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
Hm, I thought, the jar file is so small that it wouldn't be ok to leave it in scratch and have jtreg do the cleanup. I'll check if I can come up with something that would take the retain policy of jtreg into account...
More information about the core-libs-dev