RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031

Langer, Christoph christoph.langer at sap.com
Fri Apr 26 16:51:16 UTC 2019

Great, thank you. This one is a bit larger and will probably need a few iterations…

From: Lance Andersen <lance.andersen at oracle.com>
Sent: Freitag, 26. April 2019 18:45
To: Langer, Christoph <christoph.langer at sap.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; nio-dev <nio-dev at openjdk.java.net>; Alan Bateman <Alan.Bateman at oracle.com>
Subject: Re: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031

On my todo list, will get to it either later today or over the weekend.

Thank you for the reminder :-)
On Apr 26, 2019, at 11:37 AM, Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:


ping ��

I’ve rebased this change after the latest zipfs updates. I also made some further modifications. Apart from minor things, I modified the constructors of the ZipFileSystem.Entry class and I also made some post JDK-8222440 cleanup.

Please find the new webrev here: http://cr.openjdk.java.net/~clanger/webrevs/8222276.1/

The jtreg tests for zipfs are all passing.


From: Langer, Christoph
Sent: Donnerstag, 11. April 2019 16:06
To: core-libs-dev <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>>; nio-dev <nio-dev at openjdk.java.net<mailto:nio-dev at openjdk.java.net>>; Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>>; Lance Andersen <lance.andersen at oracle.com<mailto:lance.andersen at oracle.com>>
Subject: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031


working on JDK-8213031 to add posix file permission support for the zipfs, I thought it makes sense to factor out some of the changes into a separate change. Those changes reorganize and clean up some parts of the code which I think makes sense in any case.

Please review:
Bug: https://bugs.openjdk.java.net/browse/JDK-8222276
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222276.0/

In detail:
The main change is to the hierarchy of inner classes ZipFileSystem.IndexNode and ZipFileSystem.Entry (the latter extends the former). Both classes are static classes currently. It makes sense, though, to have those associated with the ZipFileSystem they belong to.
To do that, I need to add a static superclass named ZFSNode which only holds a node name and its hashcode. This class needs to exist because of the lookup implementation to find specific nodes of tze ZipFileSystem in its node map. Then the classes IndexNode extends ZFSNode and Entry extends IndexNode can be made non-static.

Further changes are:
Improve error handling for ZipFileAttributeView::get methods
improve handling for zip64 attribute/version
minor clenaups such as adding @Override annotations, whitespace fixes, private method visibility etc.

Furthermore, there is some suspicious coding in JarFileSystem:: createVersionedLinks where a temporary key node is inserted into the alias map. However, this is a singleton instance which always gets new values. I’ll open a separate bug for that and I’ll try to create a test case which demonstrates an issue with the current code.

I ran the zipfs jtreg tests successfully and will put it into our internal system as well as run it through jdk-submit.


[cid:image001.gif at 01D4FC61.06443E70]<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>

More information about the core-libs-dev mailing list