Nestmates

[Brian Goetz]

Certainly we would like it to be useful beyond Java. Extrapolating from 
Java's situation, we've told the users that a "class" is everything 
between the outermost { ... }, and defined encapsulation rules based on 
this notion of class boundary.  For various expedient reasons, at 
various points in Java's evolution (inner classes, lambda proxies, 
specialization) we've chosen to implement a single "user class" as 
multiple "VM classes", necessitating hacks and backdoors to preserve the 
user's expectations (and sometimes failing.)  It seems reasonable that 
other languages would similarly want to define an encapsulation domain 
that spans multiple VM classes (like, perhaps, C#'s "partial class" 
construct).  The nestmate concept is motivated by the problem we have 
*now*, but we'd like it to be useful beyond the immediate situation.  On 
the other hand, we don't want to extrapolate wildly to what some 
language might want, or define something that is so complicated that we 
can't predict the security consequences.

More inline.

On 1/21/2016 6:10 PM, Vlad Ureche wrote:
> Thank you for sharing these insights Brian!
>
> I think I understand the problem and the solution, but let me ask 
> three questions to make sure I understood well:
>
> 1) The NestTop attribute must contain the child classes (except 
> specializations and lambdas, which are added dynamically), right? Is 
> this for security, so another class could not pose as a NestChild to 
> access private data? What about allowing the NestTop attribute to say 
> "anyone who wants to nest here is welcome to do so"?

Security is indeed the motivation.  It's the VM's job to enforce what 
private means; while there are plenty of ways to dodge this (and we'd 
like to close some of them down), accessibility control is part of the 
integrity model of the JVM. In order to inject yourself into another 
classes' nest, you'd need to modify that classes classfile -- in which 
case you can do anything you want with their data anyway (just make all 
the fields public.)  The two attributes form a handshake.

An easy way to say "anyone who wants to nest here may do so" is to make 
your state public, and possibly enforce language-level access control to 
make sure that they've actually requested such nesting.

> 2) Why did you choose to have symmetry and transitivity? I understand 
> that having an equivalence relation allows partitioning, but it's not 
> clear to me why partitioning is important in this case.

Simplicity.  By having a partitioning, and a distinguished canonical 
member, it is very easy to determine what access control credentials are 
in play.  It also goes back to the user model -- there is some unit of 
encapsulation that the language defines (class) that determines what 
"private" means.

We could do something fancy with friends, and transitive friends, and 
marriage brokers, and itinerant priests selling indulgences, but it 
doesn't seem that the return on complexity there is worth it.

> 3) Why is the NestChild limited to a single top class?

Again, because the encapsulation model is supposed to be simple.  Just 
as each line of code belongs to only one source file, each bytecode 
belongs to one nest.  \\

Perhaps another way to think of it is: its the simplest thing we could 
think of that solves our current problem and yet seems not completely 
ad-hoc :)

> These questions stem from pondering whether we can use the nestmates 
> mechanism to implement Scala's enclosing-entity-private access 
> specifiers (e.g. a variable in class List can be 
> private[scala.collection.List] or private[scala.collection] or 
> private[scala])... Still, I don't think this can be done at the 
> granularity required by Scala, so we'll continue to have name-mangled 
> accessors where necessary :(

Right.  These are overlapping scopes of accessibility, more like 
"virtual packages" than "nestmates".  This seems like a slightly 
different problem.