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 <[email protected]> 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 >
