Hi Paul,

On 13/02/2018 4:52 AM, Paul Sandoz wrote:

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:


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



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)


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


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


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


Looks good to me.



Please ignore the spurious "version" changes.



Reply via email to