RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

[Steve Drach]

>> Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 <https://bugs.openjdk.java.net/browse/JDK-8151542>
>> 
>> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev/ <http://cr.openjdk.java.net/~sdrach/8151542/webrev/>
>> 
>> This changeset causes the URL returned from a ClassLoader.getResource(name) invocation to be reified, that is the URL is a direct pointer to either a versioned or unversioned entry in the jar file. The patch also assures that jar URL’s are always processed by the URLClassPath.JarLoader.  The MultiReleaseJarURLConnection test was enhanced to demonstrate that reified URLs are returned.  The SimpleHttpServer test helper class was moved into it’s own file.
> I was happy to see John's note on diction so I assume the method will be renamed. Have you considered making it public so that tools and libraries outside of the JDK can use this?

I opened an issue to track this — JDK-8155657.  We’d like to get this changeset, including the name change for getReifieidName, integrated as soon as we can.

> 
> One question on URLClassPath getLoader as it's not immediately obvious that this is needed. URLClassLoader specifies that any URL ending with "/" is assumed to be a directory.

Yes, and for regular jar files, that worked fine, but when we tried it with a multi-release jar we found it by passed the part of JarLoader where we open the jar file as a runtime jar, so, for example, this code fails to retrieve the correct versioned entry, returning instead the base entry.

URL[] urls = { new URL(“jar:file:/foo/multi-release.jar!/“) };
URLClassLoader cldr = new URLClassLoader(urls);
Class<?> vcls = cldr.loadClass("version.Version”);

The change just corrects the logic when working with a “jar:…..!/“ URL.


> Are you planning to update java.net.JarURLConnection as that has special handling for #runtime that will need to be replaced.

No, we are not.  Appending the #runtime fragment in URLClassPath is the way we communicate to URLJarFile that the jar should be opened as a runtime versioned JarFile.  All this changeset does is assure that the internal implementation details are not leaked to the outside world.

> 
> -Alan