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

Steve Drach steve.drach at oracle.com
Thu Apr 28 19:20:35 UTC 2016


> On Apr 28, 2016, at 12:03 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 28/04/2016 19:53, Steve Drach wrote:
>> :
>> 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.
>> 
>> 
> Can you double check the URLClassLoader spec?

We discussed it.  It seems the spec might be deficit with respect to "jar:file:/foo/multi-release.jar!/“ type URLs, but it didn’t matter when it referred to a legacy jar file.

> 
> Also I assume the URL you are want here is "file:/foo/multi-release.jar”

No, that one is correct and still works as it did before.

> as "jar:file:/foo/multi-release.jar!/" is the URL to the top-level directory in the JAR file.

The spec for JarURLconnections says

"If the entry name is omitted, the URL refers to the whole JAR file: jar:http://www.foo.com/bar/baz.jar!/“ <http://www.foo.com/bar/baz.jar!/%E2%80%9C>

that’s the way we are using it, as the location of a jar file.

I’ve ran this through jprt with test core and found no errors/failures with this change.  

> 
> -Alan




More information about the core-libs-dev mailing list