API Updates: 8191116: [Nestmates] Update core reflection, MethodHandle and varhandle APIs to allow for nestmate access

[David Holmes]

Hi Karen,

Thanks for looking at this.

On 15/02/2018 1:16 AM, Karen Kinnear wrote:
> David,
> 
> Re-reading these I had one suggestion:
> 
>> - java/lang/invoke/MethodHandles.java
>>        * <p>
>> -     * In some cases, access between nested classes is obtained by the Java compiler by creating
>> -     * an wrapper method to access a private method of another class
>> -     * in the same top-level declaration.
>> +     * Since JDK 11 the relationship between nested types can be expressed directly through the
>> +     * {@code NestHost} and {@code NestMembers} attributes.
>> +     * (See the Java Virtual Machine Specification, sections 4.7.28 and 4.7.29.)
>> +     * In that case, the lookup class has direct access to private members of all its nestmates, and
>> +     * that is true of the associated {@code Lookup} object as well.
>> +     * Otherwise, access between nested classes is obtained by the Java compiler creating
>> +     * a wrapper method to access a private method of another class in the same nest.
>>        * For example, a nested class {@code C.D}
>>
>> Updated the nested classes description to cover legacy approach and 
>> new nestmate approach.
>>
>> -     * {@code C.E} would be unable to those private members.
>> +     * {@code C.E} would be unable to access those private members.
>>
>> Fixed typo: "access" was missing.
>>
>>        * <em>Discussion of private access:</em>
>>        * We say that a lookup has <em>private access</em>
>>        * if its {@linkplain #lookupModes lookup modes}
>> -     * include the possibility of accessing {@code private} members.
>> +     * include the possibility of accessing {@code private} members
>> +     * (which includes the private members of nestmates).
>>        * As documented in the relevant methods elsewhere,
>>        * only lookups with private access possess the following capabilities:
>>        * <ul style="font-size:smaller;">
>> -     * <li>access private fields, methods, and constructors of the lookup class
>> +     * <li>access private fields, methods, and constructors of the lookup class and its nestmates
>>
>> Clarify that private access includes nestmate access.
>>
>> -     *  access all members of the caller's class, all public types in the caller's module,
>> +     *  access all members of the caller's class and nestmates, all public types in the caller's module,
> For the above, I would change this to
> * access all members of the caller’s class, all private members of 
> nestmates, all types in the caller’s package, all public …
> 
> Specifically, we are extended the PRIVATE mode as above to include 
> access to all private members of nestmates
> and this description is trying to summarize access when all possible 
> bits are set.
> None of the settings give you access to default (package-private) 
> members that a nestmate inherits from a
> different package - since the Lookup model is based on the JVMS/bytecode 
> behavior.

True - you don't get access to a nestmates inherited protected members 
declared in a different package. I certainly didn't intend to somehow 
imply that.

> I added the types in the caller’s package since PACKAGE gives you that 
> but it was missing from the existing list.

Backing up ... in 8 this method doc simply said:

"A freshly-created lookup object on the caller's class has all possible 
bits set, since the caller class can access all its own members."

It doesn't try to say what a class can access, it just makes the obvious 
statement that it can access all its own members. If that was the 
current text I would not have needed to make any adjustment for nestmates.

But for 9/10 it states:

"A freshly-created lookup object on the caller's class has all possible 
bits set, except UNCONDITIONAL. The lookup can be used to access all 
members of the caller's class, all public types in the caller's module, 
and all public types in packages exported by other modules to the 
caller's module."

This is quite a different formulation as it now tries to enumerate the 
set of accessible things - or at least gives that impression to me! But 
it is not complete as it doesn't mention non-public types in the current 
package, nor does it mention package-accessible members of types 
(whether public or not).

With nestmates we have only expanded to include private member access, 
but the original text doesn't touch on nestmates directly at all. If we 
were to say only "all private members of nestmates" then we seem to 
suggest no access to the all the other members (public, directly 
declared protected, package). But if we say "nestmates" then that may 
imply more than intended as you point out. If we say nothing then we 
again imply by omission that there is no nestmate access.

This seems to be a bit of an unwravelling thread started by the changes 
in 9. I would suggest we simply delete this sentence altogether:

"The lookup can be used to access all members of the caller's class, all 
public types in the caller's module, and all public types in packages 
exported by other modules to the caller's module."

as each of the modes, together with the "Access Checking" section of the 
class docs, define what is accessible under which mode. I don't think 
lookupModes() needs to try and restate that.

What do you think?

Thanks,
David

> thanks,
> Karen
>>
>>
>> Thanks,
>>
>> David
>>
>