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