> On 14 Feb 2017, at 05:58, Chris Hegarty <[email protected]> wrote: > > >> On 13 Feb 2017, at 22:52, Paul Sandoz <[email protected]> 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. >
