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

[David Holmes]

Hi Paul,

On 31/01/2018 12:24 PM, Paul Sandoz wrote:
>> On Jan 30, 2018, at 1:55 AM, David Holmes <david.holmes at oracle.com 
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>
>>       MethodHandle API Changes:
>>
>> - java/lang/invoke/MethodHandle.java
>>    * A non-virtual method handle to a specific virtual method implementation
>>    * can also be created.  These do not perform virtual lookup based on
>>    * receiver type.  Such a method handle simulates the effect of
>> - * an {@code invokespecial} instruction to the same method.
>> + * an {@code invokespecial} instruction to the same non-private method;
>> + * or an {@code invokevirtual} or {@code invokeinterface} instruction to the
>> + * same private method (as applicable).
>>
>> I tried to clarify that non-virtual invocations are not limited to 
>> invokespecial - as private invocations via invokevirtual or 
>> invokeinterface are also non-virtual.
>>
>>
> 
> Why s/same method/same non-private method/ for the invokespecial?
> 
> It’s possible to look up a private method within the same class using 
> Lookup.invokespecial and invoke it (and also look up a private 
> constructor and invoke it).

Yes you are right, but this text is not trying to describe how an 
invokespecial might be used, but rather how "A non-virtual method handle 
to a specific virtual method implementation can also be created."

But the notion of "specific virtual method implementation" is perhaps 
not applicable to private methods in the first place.

Perhaps I just need to remove this change altogether and leave it as-is.

Thanks,
David

> Paul.