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

[Langer, Christoph]

Hi Lance,

thanks for the review.

I checked again whether I would remove an important test path for testing the ability to create mr jars with the jar tool. But I see this is tested for instance in test/jdk/java/util/jar/JarFile/mrjar and probably in other places as well.

So I’ll push my change as is after running some further tests.

Thanks
Christoph

From: Lance Andersen <lance.andersen at oracle.com>
Sent: Dienstag, 23. April 2019 12:49
To: Langer, Christoph <christoph.langer at sap.com>
Cc: core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8222440: (zipfs) JarFileSystem does not correctly handle versioned entries if no root entry is present

Hi Christoph
On Apr 23, 2019, at 5:37 AM, Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:

Hi Lance,


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.

Thank you for the follow up.

No the restructure of the test and getting rid of the  directory tree and just building the jar within the test is good

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…

I do not have a strong preference either way.    In the past, I have been suggested to clean up anything created.  I agree it can be handy if it these types of things remain after a failure

I think you are good to go.

Best
Lance


Best regards
Christoph

[cid:image001.gif at 01D4FB7A.550DD9E0]<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.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>