RFR: 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them

[John Rose]

Diction Note: Reified X means X wasn't real (in some sense) until now. As in non-reified types, which are not real at runtime because the static compiler discarded them. 

In this case it appears you are simply exposing a translated name, not making it real for the first time. 

If this is true, I think you want to say "true name" or "real name" or "translated name", not "reified name".

– John

> On Apr 27, 2016, at 2:58 PM, Steve Drach <steve.drach at oracle.com> wrote:
> 
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8151542 <https://bugs.openjdk.java.net/browse/JDK-8151542>
> 
> Webrev: http://cr.openjdk.java.net/~sdrach/8151542/webrev/ <http://cr.openjdk.java.net/~sdrach/8151542/webrev/>
> 
> This changeset causes the URL returned from a ClassLoader.getResource(name) invocation to be reified, that is the URL is a direct pointer to either a versioned or unversioned entry in the jar file. The patch also assures that jar URL’s are always processed by the URLClassPath.JarLoader.  The MultiReleaseJarURLConnection test was enhanced to demonstrate that reified URLs are returned.  The SimpleHttpServer test helper class was moved into it’s own file.