Updated nestmates spec

[Dan Smith]

Yes, while not part of the proposed feature set, it would make sense to have ACC_PRIVATE classes in the JVM, with a requirement that a private class can only be accessed from a nestmate (or itself). That change would be a self-contained feature that could be squeezed in wherever it's convenient.

ACC_PACKAGE still doesn't make sense for classes in the JVM, because there is no concept of type membership or inheritance. Package-access classes will still have to be compiled as ACC_PUBLIC.

—Dan

> On Oct 11, 2017, at 12:13 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> One thing I didn't see in the spec: the access check on classes.  For example, given:
> 
>     class C {
>         private class D {
>             private int x;
>         }
>     }
> 
> D.x is accessible to C because (class check) D and C are in the same package, and (member check) D and C are in the same nest.
> 
> We erase the "private" modifier when we write out the classfile for D.  But, with nestmates, we shouldn't have to do that; we should be able to mark D as ACC_PRIVATE, and amend 5.4.4 to have a fourth bullet for "class or interface C is accessible to a class or interface D" section, which says "members of the same nest."
> 
> This should affect all access to D members, and also affect "C implements C.D", where C.D is private, scenarios.
> 
> On 10/6/2017 2:00 PM, Dan Smith wrote:
>> I've posted an update to the nestmates spec based on discussions of the last few months.
>> 
>> http://cr.openjdk.java.net/~dlsmith/nestmates.html
>> 
>> Significant changes:
>> - Renamed MemberOfNest --> NestHost, per some requests; it seems more consistent with names of other attributes
>> - Eliminated checking of the NestHost attribute during verification. This means the nest of a class is computed lazily when access is requested, and we have to account for live classes whose NestHost attribute is invalid
>> 
>> I considered and rejected a proposal to guard 'invokeinterface' behavior changes on the class file version number. Consensus was that behavioral changes that replace errors with successful execution are acceptable when running old class files.
>> 
>> Feedback is always welcome.
>> 
>> —Dan
>