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

John Rose john.r.rose at oracle.com
Wed Apr 27 22:26:08 UTC 2016

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.

More information about the core-libs-dev mailing list