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() { ... }
}
