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

John Rose john.r.rose at oracle.com
Thu Apr 28 00:10:26 UTC 2016

On Apr 27, 2016, at 4:20 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> On 27 Apr 2016, at 15:26, John Rose <john.r.rose at oracle.com> wrote:
>> 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.
> I suggested reified because i thought it fit with the notion of making something abstract more concrete, but perhaps this just confuses matters?

It's the real name, but since it already exists (because that's how it is stored) it isn't really reified, it's just revealed.

This API uses the term "real name" for an almost identical phenomenon (target of a sym-link in a file system):


In a versioned jar, the logical names are sometimes mapped to other names under which the elements are actually stored.
Thus, they behave like sym-links.  (But with a bit of control context thrown in, the active version.)

On old-fashioned file systems with real version numbers, the Common Lisp function TRUENAME does exactly what you are trying to do here.


(And in some way, we are sliding down the slope toward re-inventing those file systems, aren't we?)

The older pre-nio API for File calls it "getCanonicalPath", but I think "true name" is better than
"canonical name", since "canonical" means "follows the rules", rather than what we need in this case,
which is "where it really is stored".


>> 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”.
> or “versioned name" would work for me.

I'm just whinging about the term "reified" which doesn't seem to work, logically.

"Versioned name" would work for me too.  But "true name" has the two good precedents cited above.

— John

More information about the core-libs-dev mailing list