RFR 8174151: URLClassLoader no longer uses custom URLStreamHandler for jar URLs

[Paul Sandoz]

> On 14 Feb 2017, at 05:58, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
>> On 13 Feb 2017, at 22:52, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review.
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8174151-url-class-path-loader/webrev/index.html
> 
> If I understand this correctly then the only optimisation ( by-pass of
> openConnection ), which is causing the problem, is when the URL
> is of the form “jar:file:xxxxx!/“, right? If so, you could limit the scope
> of your changes to only fall back to Loader when the nested URL
> has a “file” protocol. This would give you MR JAR functionality for
> "jar:http://xxx”, which is fairly common.
> 

We need to tunnel, by default, all jar: URL resources through the JarLoader which creates and caches the runtime versioned JarFile and returns an appropriately URL (to a versioned resource if necessary).

(Note that there is already an optimization in the internal JarURLConnection to bypass access to the jar file via the embedded URL is the embedded scheme is file:)

Paul.

>> This is a nasty edge case when a URLStreamHandler is registered (via the system property) to process jar: URLs.
>> 
>> The support for multi-release JAR files changed the implementation of ClassLoader.findResource such that the to be returned jar: URLs would not be operated on, and therefore the jar: URLStreamHandler would not be queried [*]. If the returned jar: URL is operated on by the caller then the jar: URLStreamHandler would (of course) be queried.
>> 
>> This is arguably an implementation detail but it does change long term established behaviour in a very delicate area.
>> 
>> While i find it unpalatable to do so this patch restores the previous behaviour, if a custom jar: URLStreamHandler is registered. The compromise is such a custom jar: URLStreamHandler needs to explicitly support multi-release JAR files.
>> 
>> Paul.
>> 
>> [*] Note that there are already such optimisations for file: URLs.
> 
> -Chris.
>