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

[David Holmes]

Hi Paul,

On 1/02/2018 2:48 AM, Paul Sandoz wrote:
>> On Jan 30, 2018, at 7:22 PM, David Holmes <david.holmes at oracle.com> wrote:
>> 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.”
>>
> 
> Ok, i see now.
> 
> 
>> 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.
>>
> 
> I would be inclined just to leave it as is.

I decided to restore the original text and then add the following - as I 
do want to make it clear that non-virtual is not restricted to 
invokespecial:

* A non-virtual method handle can also be created to simulate the effect
* of an {@code invokevirtual} or {@code invokeinterface} instruction on
* a private method (as applicable).

I have updated specdiffs for all of the changes here:

http://cr.openjdk.java.net/~dholmes/8010319/specs/java.lang/overview-summary.html
http://cr.openjdk.java.net/~dholmes/8010319/specs/java.lang.invoke/overview-summary.html
http://cr.openjdk.java.net/~dholmes/8010319/specs/java.lang.reflect/overview-summary.html

Please ignore the spurious "version" changes.

Thanks,
David
-----

> Paul.
>