RFR - 8132734: java.util.jar.* changes to support multi-release jar files

[Paul Sandoz]

> On 8 Nov 2015, at 16:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 05/11/2015 17:10, Steve Drach wrote:
>> Hi,
>> 
>> Here’s a new webrev that addresses the issues Paul brought up.  The versioned entry cache has been removed, the search space has been reduced, the documentation for setVersioned(int) and setRuntimeVersioned() has been updated to clarify when IllegalStateException is thrown, and the tests have been changed to accommodate a jar file with versions 9 and 10, rather than 8 and 9.
>> 
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734>
>> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 <https://bugs.openjdk.java.net/browse/JDK-8047305>
>> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/>
>> 
> I assume adding #rtversioned to JAR URLs will need discussion. I don't know if you are planning to include this in the first push or not but I assume it will require changes to the JAR URL scheme defined in java.net.JarURLConnection. I'm sure there is lots of code in the wild that parses JAR URLs.

I was wondering if it might be possible to consider this a mostly internal contract since the URL class loading functionality (URLClassPath.java) creates such URLs for processing by JarURLConnection in some code paths (getResourceAsStream IIRC). Since JarURLConnection caches JarFiles we need to distinguish between runtime class loading behaviour and independently created URLs.

A fragment is the most unobtrusive way to do this, and i think a reasonably accurate use of the URL syntax.

I expect we will have to say something since these URLs will pop out from ClassLoader.getResource.

Paul.

> 
> I looked through JarFile and don't seem anything obviously wrong. The property jdk.util.jar.multirelease is a bit unusual, an alternative name for the property might be jdk.util.jar.enableMultiRelease with "true", "false" and "force" as possible values.
> 
> I skimmed over the tests and good to see that you pulled back from checking in binary JAR files. As JarFile is Closeable then you could use try-with-resources to ensure the JAR files are closed, otherwise test failures will leave files open.
> 
> -Alan.
> 
> 
> 
> 
>