Draft JVMS changes for Nestmates

[Brian Goetz]

> JEP name
>
> I don't know how permanent JEP names are supposed to be, but I'd prefer a different name at this point. Something like: "Expanded JVM Access to Private Members"—shorter, focused on the feature itself rather than its relationship to the Java language. Or maybe "Class Nests for Access to Private Members".

I like the latter; it captures the core feature here, which is 
introducing a new concentric sphere of access control in the VM, which 
we call "nests".  That it was inspired by translation challenges in 
Java, or useful to addressing those, is secondary.

> Terminology
>
> The term "nest" is nice because it's short and mostly unspoiled by overloading in this context (I think?); it's not great because it's informal and doesn't mean anything the first time you hear it. I thought about something more clinical like "access control context", but I'm not convinced that's an improvement. How do others feel?

Nest connotes "things in other things", like Matryoshka dolls, which I 
think is a positive.


> The JEP uses "nest top" to describe the class that nest members reference; I prefer "host class", which better describes the class's role and isn't tied to the Java "top level class" concept. I know we use "host class" internally in Hotspot, perhaps when working with anonymous classes (of the JVM flavor), but I think in that context it will ultimately mean the same thing? Are we comfortable repurposing the term in this way?

Or: "nest host" or "nest host class" or "nest parent" ...

The primary purpose of having a nest top is so that there is a 
well-defined canonical member of each nest, to which we can attach all 
the nest metadata and ensure that computations regarding nest-ness are 
well-defined.  It doesn't have to be the "top" class at the language 
level.  I think the term should connote canonical-ness rather than top-ness.

> I follow Brian's model when it comes to nest membership (5.4.4): every class belongs to a nest, possibly (in the absence of MemberOfNest) the nest hosted by itself. Many nests are singletons without any associated explicit attributes.

More precisely: nests form a /partition/ over classes.  This means every 
class belongs to exactly one nest, so the function Nest(Class) is total.

> Compiler changes
>
> The JEP text can't seem to decide if compiler changes are part of it, or a follow-up exercise. I think we're best off explicitly including the compiler changes, which will provide opportunities for design validation and testing.

That was my bad.  I was trying to capture that we didn't require an 
immediate flag day -- that for any given compiler, dropping access 
bridges out of the compiler implementation could happen any time after 
the VM acquired nestmate support -- but for our own implementation, we'd 
be silly to not get the test and validation benefit of dropping 
unnecessary bridge generation ASAP.

> API changes

We need to decide whether we are delivering a reflection component, and 
if so, what that looks like.

Minimal candidate:

     class Nest {
         Class<?> hostClass() { ... }
         boolean isMember(Class<?> clazz) { .... }
     }

     class Class {
        Nest getNest() { ... }
     }