> On 8 Nov 2015, at 21:21, Alan Bateman <alan.bate...@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.
