RFR - 8132734: java.util.jar.* changes to support multi-release jar files

[Paul Sandoz]

> On 9 Nov 2015, at 21:53, Steve Drach <steve.drach at oracle.com> wrote:
> 
>>>> As to whether this is implementation vs. JAR URL spec then I assume it needs to be spec so that libraries can create URLs that will use runtime versioning when access the JAR.
>>>> 
>>> 
>>> Yeah, i don’t think we can avoid it.
>> 
>> Ok.  I guess I should put the information in JarURLConnection.
> 
> Actually it’s a bit strange documenting the #runtime fragment in JarURLConnection, because none of the changes are in that class.  The changes are in the sun.net.www.protocol.jar.JarURLConnection class that is not publicly documented.
> 

You can document it as a “should” requirement for subclasses of j.n.JarURLConnection. For example:

  Subclasses of JarURLConnection that support multi-release JAR files should support URLs that refer to
  JAR runtime versioned entries. Such a URL is a URL referring to an entry modified to include the fragment “runtime”.
  Subclasses that do not support multi-release JAR files should ignore the fragment and process such URLs as if the
  fragment were not present.

Then you can refer to an example.

There is a chance that the fragment might perturb existing subclasses, likely only if the URL parsing is buggy. Grepcode does not report many external subclasses:

http://grepcode.com/search/usages?id=repository.grepcode.com$java$root@jdk$openjdk@7u40-b43@java$net@JarURLConnection&start=0&type=type&k=d

It’s more common to register a URLStreamHandlerFactory via URL.setURLStreamHandlerFactory. I suspect that is used more for supporting different URL schemes than for overriding the “jar” scheme. This is a very delicate area, override the “jar" scheme might be risky given the interaction with class loaders. IMO the URLs returned from JDK ClassLoaders should be using URL schemes that are not overridable, but it’s probably too late to change that.

Paul.