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

[Paul Sandoz]

> 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?)

  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);

?

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
  assert nh.isNestmateOf(nh)
  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)));

?

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.

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.


> 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.

Paul.

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