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
