RFR: JDK-8038500: (zipfs) Upgrade ZIP provider to be a supported provider

Erik Joelsson erik.joelsson at oracle.com
Tue Apr 15 07:48:37 UTC 2014

Hello Sherman,

The build changes look good to me.


On 2014-04-14 19:52, Xueming Shen wrote:
> Thanks Mandy and Alan for the review.
> webrev has been updated accordingly to
> (1) Removed the basic.sh. The tests are now using test.jdk to access 
> the zipfs.jar directly
> (2) Updated most of the class to package package, only 
> ZipFileSystemProvider (the spi interface)
>      and ZipInfo are public.
>      The ZipInfo is a handy utility sometime I find it useful to 
> simply do java com.sun.nio.zipfs.Info xyz.zip
>      to display all cen and loc tables in details. I may take sometime 
> to find a better home for it later.
> (3) I have not migrated the test target zipfs.jar to an "independent" 
> test source (created during test) yet,
>      will definitely later in a separate thread when we move to modules.
> (4) Yes, I mean to keep Demo there as an interactive regression test.
> http://cr.openjdk.java.net/~sherman/8038500/webrev/
> -Sherman
> On 4/11/14 4:29 PM, Mandy Chung wrote:
>> On 4/11/2014 3:42 PM, Xueming Shen wrote:
>>> webrev: http://cr.openjdk.java.net/~sherman/8038500/webrev
>> It's good to see the source of the zip provider moved to the jdk 
>> repo.   You have made some public classes to package-private which is 
>> good.  I wonder whether a few remaining public classes can be made 
>> package-private (e.g. ZipFileAttributes, ZipInfo etc).  Is 
>> JarFileSystemProvider used anywhere? ZipFileSystemProvider is the 
>> only provider listed in the service configuration.
>> Do you mean to make Demo.java as a regression test?
>> basic.sh - I wonder if you can get rid of this shell test.  Do Basic, 
>> PathOps, ZipFSTester have any relationship?  I was thinking if they 
>> can be made as individual java test and constructor the input path of 
>> zipfs.jar.    With zipfs.jar part of the jdk build, it will be found 
>> under ${java.home}/lib/ext/zipfs.jar.   When we move to modules, this 
>> jar file won't exist.  It might be better for the tests to create a 
>> JAR file (one to share by all zipfs tests) to get ready for modules.
>> Mandy

More information about the core-libs-dev mailing list