RFR 8144355: JDK 9 changes to ZipFileSystem to support multi-release jar files

[Steve Drach]

Hi,

I’ve updated the webrevs to take into account Sherman’s comments.

Issue: https://bugs.openjdk.java.net/browse/JDK-8144355 <https://bugs.openjdk.java.net/browse/JDK-8144355>

Change to modules.xml: http://cr.openjdk.java.net/~sdrach/8144355/top/webrev.01/index.html <http://cr.openjdk.java.net/%7Esdrach/8144355/top/webrev.00/index.html>

Changes to ZipFileSystem: http://cr.openjdk.java.net/~sdrach/8144355/jdk/webrev.01/index.html <http://cr.openjdk.java.net/~sdrach/8144355/jdk/webrev.01/index.html>

Thanks,
Steve

>> On Dec 14, 2015, at 9:46 AM, Xueming Shen <xueming.shen at oracle.com <mailto:xueming.shen at oracle.com>> wrote:
>> 
>> Hi Steve,
>> 
>> (1) ZipFileSystem.getParent() might no longer need to be changed to "package private"? I don't
>>      see it is used by other.
> 
>> (2) For JarFileSystem.isMultiReleaseJar(), the alternative is to use the public api directly
>> 
>>     try (InputStream is = getInputStream(getBytes("META-INF/MANIFEST.MF"))) {
> 
>>         new Manifest(is).getMainAttributes().containsKey(new Attributes.Name("Multi-Release")); 
>>     } catch (Exception x) {}
>>     return false; 
>> 
>>     In this approach, the getInputStream(Entry) can be put back to "private" as well.
>>     But this is just a personal preference, your choice:-)
>> 
>> The rest looks fine for me
>> 
>> Thanks,
>> Sherman
>> 
>> On 12/14/15 9:14 AM, Steve Drach wrote:
>>> Hi,
>>> 
>>> I sent this out a week ago.   Resending to bump it to the top of the stack.
>>> 
>>> Please review the changes and additions to ZipFileSystem to support multi-release jars as described in JEP 238 <http://openjdk.java.net/jeps/238>.
>>> 
>>> The strategy is, if a file system is created over a multi-release jar,  a map of root entries to versioned entries for a specific platform release version is constructed.  The desired platform release version is configured through the the env parameter given to the FileSystem.newFileSystem method.  Then when a root entry is requested, the map is consulted and if a mapping is found, the corresponding versioned entry is returned.  Very similar to symbolic links.
>>> 
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8144355 <https://bugs.openjdk.java.net/browse/JDK-8144355>
>>> 
>>> Change to modules.xml: http://cr.openjdk.java.net/~sdrach/8144355/top/webrev.00/index.html <http://cr.openjdk.java.net/%7Esdrach/8144355/top/webrev.00/index.html>
>>> 
>>> Changes to ZipFileSystem: http://cr.openjdk.java.net/~sdrach/8144355/jdk/webrev.00/index.html <http://cr.openjdk.java.net/%7Esdrach/8144355/jdk/webrev.00/index.html>
>>> 
>>> Thanks,
>>> Steve
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20151214/b8dc04a9/attachment.html>