<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 30, 2018, at 1:55 AM, David Holmes <<a href="mailto:david.holmes@oracle.com" class="">david.holmes@oracle.com</a>> wrote:</div><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><h3 class="">MethodHandle API Changes:</h3>
    <pre class="">- java/lang/invoke/MethodHandle.java</pre>
    <pre class="">  * 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).
</pre><p class="">I tried to clarify that non-virtual invocations are not limited
      to invokespecial - as private invocations via invokevirtual or
      invokeinterface are also non-virtual.</p><div class=""><br class=""></div></div></div></blockquote><br class="">Why s/same method/same non-private method/ for the invokespecial?</div><div><br class=""></div><div>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).</div><div><br class=""></div><div>Paul.</div></body></html>