> On 8 Nov 2015, at 16:51, Alan Bateman <alan.bate...@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. > > > > >
