> On Jan 30, 2018, at 7:22 PM, David Holmes <david.hol...@oracle.com> wrote: > > Hi Paul, > > 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. Paul.
