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

[Paul Sandoz]

> On 29 Apr 2016, at 13:46, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 29/04/2016 19:36, Steve Drach wrote:
>> I put a new webrev out with the change suggested by Paul, using file.indexOf(“!/“) instead of file.endsWith(“!/“).
>> 
>> http://cr.openjdk.java.net/~sdrach/8151542/webrev.02/index.html
> This still needs to be fixed to compare the URL protocol without regard to case (yes, some of the old code isn't right but best not to make it worss).
> 

That triggered me to look at this much more closely.

AFAICT URL instances do canonicalize the protocol to lower case, so it’s only where the raw URL characters are checked that this would need to be done.

Steve is there a case whereby when you extract the nested URL from a jar URL it would ever get routed to Loader or FileLoader? It seems it would always route to JarLoader. If so, off the top of my head, could you do:

    String protocol = url.getProtocol();
    String file = url.getFile();
    if ("jar".equals(protocol) && file != null && file.indexOf("!/") == file.length() - 2) {
        // jar: protocols
        URL nestedUrlToJarFile = new URL(file.substring(0, file.length() - 2));  // extract the nested URL
        return new JarLoader(nestedUrlToJarFile, jarHandler, lmap);
    } else if ("file".equals(protocol)) {
        // file: protocols
        if (file != null && file.endsWith("/“)) {
            // Exploded from base directory
            return new FileLoader(url);
        } else {
           // Assumed to be a jar file
           return new JarLoader(url, jarHandler, lmap);
        }
    } else {
        // Fallback to URL connection
        return new Loader(url);
    }

That makes all the cases much clearer.

?

Paul.

>> 
>>> So you are planning to eventually change the URLClassLoader spec to allow this or not?
>> 
>> I think we should push this changeset since URLClassLoader has always accepted the jar:…!/ URL and all this changeset does is enable it  to support multi-release jars.  And create an issue to track the change to the URLClassLoader api.
>> 
> There shouldn't be any urgency with this change going in but if you are doing it this way then please create a high priority bug to get the spec and implementation aligned.
> 
> -Alan