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

[David Holmes]

Hi Paul,

On 13/02/2018 4:52 AM, Paul Sandoz wrote:
> 
> 
>> On Feb 11, 2018, at 5:19 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> 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
> 
> If a class has no nestmates is it implicitly a nest of itself? (is that considered something valid?)

Yes - as John said. Every class is a member of some nest, even if that 
is a singelton nest consistenting only of itself. That is the default if 
there is no nesthost attribute.

>    Class c = … // some class with no nest mates
>    assert c.getNestHost() == c
>    assert c.isNestmateOf(c)
>    assert Stream.of(c.getNestMembers()).anyMatch(_c -> _c == c);
> 
> ?

Yes.

> If class nh is a nest host with nest mates (in addition to itself):
> 
>    Class nh = … // some class that is a nest host
> 
>    assert nh.getNestHost() == c

No, nh.getNestHost == nh

>    assert nh.isNestmateOf(nh)

Yes.

>    assert Stream.of(nh.getNestMembers()).anyMatch(_c -> _c == nh);
>    assert Stream.of(nh.getNestMembers()).allMatch(_c -> _c.isNestmakeOf(nh));
>    assert Stream.of(nh.getNestMembers()).allMatch(
>      _c -> Stream.of(nh.getNestMembers()).allMatch(__c -> __c.isNestmakeOf(_c)));
> 
> ?

Yes - ignoring your typo and assuming I'm reading those expressions right.

> getNestMembers
> —
> 
> "The list of nest members in the classfile is permitted to contain duplicates, or to explicitly include the nest host. It is not required that an implementation of this method removes these duplicates."
> 
> The "or to explicitly include the nest host” suggests it might not include the nest host, but a prior statement says it will be present in the zeroth element.

The "or" pertains to the list of nest members in the classfile - ie the 
contents of the NestMembers attribute. The returned array of nestmembers 
will always contain the nesthost as the zeroeth element, but may also 
contain it somewhere else if the classfile explicitly listed it in 
nestmembers.

> Why the ambiguity over duplicates? is this motivated by performance? this may just push the cost to clients that have to always remove duplicates to function reliably and may be cause bugs if duplicates are rare and induced by certain relationships or loading patterns. My inclination would be for the returned array to not contain duplicates.

Yes performance. Having to check for duplicates adds a cost to every 
single well formed call to this API to account for something that the 
specification allows to happen but which we don't expect to happen and 
which javac will never produce. This has all been discussed previously.

> 
>> 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
>>
> 
> Looks good to me.

Thanks,
David
-----

> Paul.
> 
>> Please ignore the spurious "version" changes.
>>
>> Thanks,
>> David
>> -----
>>
>>> Paul.
>