> On Feb 11, 2018, at 5:19 PM, David Holmes <david.hol...@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.hol...@oracle.com> wrote:
>>> On 31/01/2018 12:24 PM, Paul Sandoz wrote:
>>>>> On Jan 30, 2018, at 1:55 AM, David Holmes <david.hol...@oracle.com 
>>>>> <mailto:david.hol...@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)));



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


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

Reply via email to