On 01/15/2018 10:43 AM, Karen Kinnear wrote: > EG members - could you possibly review this change and reply in an email? > We believe this is the last step to finalizing the nestmates JVMS changes.
Seems OK to me. My only meta-thought is that nestmates might now hold the record for the most subtle details that needed addressing per unit of benefit to the platform... -Doug > > thanks, > Karen > > p.s. changes are relative > to: http://cr.openjdk.java.net/~dlsmith/nestmates.html > >> On Jan 10, 2018, at 9:34 AM, Karen Kinnear <karen.kinn...@oracle.com >> <mailto:karen.kinn...@oracle.com>> wrote: >> >> David Holmes and I are good with Dan’s proposal here. >> >> thanks, >> Karen >> >>> On Jan 9, 2018, at 5:27 PM, Dan Smith <daniel.sm...@oracle.com >>> <mailto:daniel.sm...@oracle.com>> wrote: >>> >>>> On Jan 3, 2018, at 9:16 AM, Karen Kinnear <karen.kinn...@oracle.com >>>> <mailto:karen.kinn...@oracle.com>> wrote: >>>> >>>> In studying the details of these changes, there are three sets of >>>> changes that change the behavior of invokeinterface. >>>> >>>> 1. Invokeinterface is allowed to resolve to a private member of the >>>> reference class, and the resolved method becomes the selected >>>> method. >>>> 2. 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. >>>> 3. 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. >>>> >>>> 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. >>>> >>> >>> This is a good change; see details below. >>> >>> Eventually, I would like to entirely get rid of this rule, but to do >>> so we need a more comprehensive solution to JDK-8021581. >>> >>>> 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. >>>> >>>> >>> >>> 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.) >>>> >>>> >>>> Run-time Exceptions >>>> >>>> Otherwise, if step 1 or step 2 of the lookup procedure selects a >>>> method that is not |public|, |invokeinterface| throws >>>> an |IllegalAccessError|. >>>> >>>> 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. >>>> >>> >>> Concretely, we would undo this deletion, and instead modify the rule >>> as follows: >>> >>> "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." >>> >>> 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. >>> >>> —Dan >> >
