RFR - 8132734: java.util.jar.* changes to support multi-release jar files
Alan.Bateman at oracle.com
Sun Nov 8 15:51:53 UTC 2015
On 05/11/2015 17:10, Steve Drach wrote:
> 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