> On Apr 28, 2016, at 12:03 PM, Alan Bateman <alan.bate...@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
