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

[Paul Sandoz]

> On 8 Nov 2015, at 21:21, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 08/11/2015 19:36, Paul Sandoz wrote:
>> :
>> 
>> I was wondering if it might be possible to consider this a mostly internal contract since the URL class loading functionality (URLClassPath.java) creates such URLs for processing by JarURLConnection in some code paths (getResourceAsStream IIRC). Since JarURLConnection caches JarFiles we need to distinguish between runtime class loading behaviour and independently created URLs.
>> 
>> A fragment is the most unobtrusive way to do this, and i think a reasonably accurate use of the URL syntax.
>> 
> I can go along with using a URL fragment although the proposed value (rtversionsed) is a little bit strange.
> 

The name is derived from the requirement that if the fragment is present a call to getRuntimeVersionedEntry is required (or the equivalent of), thus the URL is a reference to a runtime versioned entry.


> 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.


> I just read the mails about the configured setting, I just wonder if there could be any interaction with JAR cache as it's not keyed on whether it is runtime versioned.
> 

Do you mean caching by JarFileFactory? AFAICT it’s only used by JarURLConnection and that never configures JarFiles, which is why we need the fragment.

Paul.