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> 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. >> Invokeinterface is allowed to resolve to a private member of the reference >> class, and the resolved method becomes the selected method. >> 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. >> 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
