<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="">EG members - could you possibly review this change and reply in an email?<div class="">We believe this is the last step to finalizing the nestmates JVMS changes.<br class=""><div class=""><br class=""></div><div class="">thanks,</div><div class="">Karen</div><div class=""><br class=""></div><div class="">p.s. changes are relative to: <a href="http://cr.openjdk.java.net/~dlsmith/nestmates.html" class="">http://cr.openjdk.java.net/~dlsmith/nestmates.html</a><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 10, 2018, at 9:34 AM, Karen Kinnear <<a href="mailto:karen.kinnear@oracle.com" class="">karen.kinnear@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">David Holmes and I are good with Dan’s proposal here.<div class=""><br class=""></div><div class="">thanks,</div><div class="">Karen<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 9, 2018, at 5:27 PM, Dan Smith <<a href="mailto:daniel.smith@oracle.com" class="">daniel.smith@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="">On Jan 3, 2018, at 9:16 AM, Karen Kinnear <<a href="mailto:karen.kinnear@oracle.com" class="">karen.kinnear@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p class="" style="margin: 10px 0px 0px; padding: 0px; color: rgb(51, 51, 51); font-family: Arial, sans-serif;">In studying the details of these changes, there are three sets of changes that change the behavior of invokeinterface.</p><ol class="" style="margin: 10px 0px 0px; color: rgb(51, 51, 51); font-family: Arial, sans-serif;"><li class="">Invokeinterface is allowed to resolve to a private member of the reference class, and the resolved method becomes the selected method. </li><li class="">The removal of the invokeinterface selection runtime access check, allows selection of a package-private or protected method, since they can override a public method from the resolution step.</li><li class="">The combining of the invokeinterface selection and invokevirtual selection (and equivalent preparation modifications) add the concept of "overrides" to the invokeinterface selection lookup steps. Note that private methods never override and are never overridden. The consequence of this change is that the invokeinterface selection lookup will now SKIP private methods as invokevirtual does, where before it would find the private method and throw an IllegalAccessError.</li></ol><p class="" style="margin: 10px 0px 0px; padding: 0px; color: rgb(51, 51, 51); font-family: Arial, sans-serif;">I am proposing that for nestmates we do not need the second change, and that we could continue to have invokeinterface and invokevirtual selection be aligned, while keeping the restriction that if the selection lookup procedure selects a method that is not public, invokeinterface throws an IllegalAccessError. (This would continue to allow resolution to a private member, select the same private member). This prevents adding additional cases in which the caller is able to invoke a method it can not directly access.</p></div></blockquote><div class=""><br class=""></div><div class="">This is a good change; see details below.</div><div class=""><br class=""></div><div class="">Eventually, I would like to entirely get rid of this rule, but to do so we need a more comprehensive solution to JDK-8021581.</div><br class=""><blockquote type="cite" class=""><div class=""><p class="" style="margin: 10px 0px 0px; padding: 0px; color: rgb(51, 51, 51); font-family: Arial, sans-serif;">For the 3rd change we have two ways to approach this. We can leave the existing invokeinterface selection/preparation alone, find private methods in the receiver and its superclasses, and throw an IllegalAccessError, or we can make the proposed changes and skip private methods as we do for invokevirtual (because of the term "overrides") and potentially find a public method that overrides the resolved method.</p><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I have not yet heard a concrete proposal to make changes here, and continue to think the best thing to do is merge the selection logic into one set of rules, as described in the nestmates spec document. (It is *possible* to achieve our goals through other means, but there are many pitfalls, and I haven't seen anyone arguing for a specific alternative. From where I sit, the current proposed approach seems best.)</div><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div style="margin: 0px; padding: 0px;" class=""><h3 id="NestmatesInvocationChange-ProposedModification-Run-timeExceptions" style="margin: 30px 0px 0px; padding: 2px; font-size: 16px; line-height: 1.5; color: rgb(51, 51, 51); background-color: rgb(240, 240, 240);" class="">Run-time Exceptions</h3><p style="margin: 10px 0px 0px; padding: 0px;" class=""><span style="color: rgb(153, 51, 0);" class=""><span style="text-decoration: line-through;" class="">Otherwise, if step 1 or step 2 of the lookup procedure selects a method that is not </span><code style="text-decoration: line-through;" class="">public</code><span style="text-decoration: line-through;" class="">, </span><code style="text-decoration: line-through;" class="">invokeinterface</code><span style="text-decoration: line-through;" class=""> throws an </span><code style="text-decoration: line-through;" class="">IllegalAccessError</code><span style="text-decoration: line-through;" class="">.</span></span></p><p style="margin: 10px 0px 0px; padding: 0px;" class="">This is the line that we believe could be restored, slightly modified to apply to the selection lookup procedure steps in 5.4.5, so that the only non-public selected method would be a private method which is the referenced method as well as the selected method.</p></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Concretely, we would undo this deletion, and instead modify the rule as follows:</div><div class=""><br class=""></div><div class="">"Otherwise, if step 1 or step 2 of the lookup procedure selects a method that is ~~not public~~ **neither public nor private**, invokeinterface throws an IllegalAccessError."</div><div class=""><br class=""></div><div class="">The motivation here is that invokeinterface is uniquely able to i) resolve to a public interface method, and ii) select a protected/package method of a superclass that would otherwise be inaccessible to the caller. The fact that the referenced method is in an interface is important, because anyone with the ability to extend a class can also declare a fresh superinterface that includes any method names+descriptors they're interested in.</div><div class=""><br class=""></div><div class="">—Dan</div></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></body></html>