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

Paul Sandoz paul.sandoz at oracle.com
Thu Apr 28 20:21:52 UTC 2016


> On 28 Apr 2016, at 12:20, Steve Drach <steve.drach at oracle.com> wrote:
> 
> 
>> 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.
> 

It appears to be an undocumented “feature" that URLClassLoader can accept base jar-scheme URLs such as:

  jar:file/….!/
  jar:http/….!/

by virtue of those URLs being passed to URLClassPath, which is contrary to what is stated on URLClassLoader:

"Any URL that ends with a '/' is assumed to refer to a directory. Otherwise, the URL is assumed to refer to a JAR file which will be opened as needed.”

The above only reliably applies to file-scheme URLs.

Here is the original logic:

String file = url.getFile();
if (file != null && file.endsWith("/")) {
    if ("file".equals(url.getProtocol())) {
        return new FileLoader(url);  <—— exploded class loading
    } else {
        return new Loader(url); <—— uses URL connection, can process the jar file referenced by jar:file:/…!/
    }
} else {
    return new JarLoader(url, jarHandler, lmap);  <—— fall back, always the URL references a jar file
}

Paul.



More information about the core-libs-dev mailing list