> On 13 Feb 2017, at 22:52, Paul Sandoz <paul.san...@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. > 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.
