> On Jan 3, 2018, at 9:16 AM, Karen Kinnear <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
