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

Alan Bateman Alan.Bateman at oracle.com
Sun Nov 8 15:51:53 UTC 2015

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 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.


More information about the core-libs-dev mailing list