RSVP please: Re: Nestmates JVMS changes to selection and behavior implications
karen.kinnear at oracle.com
Mon Jan 15 15:43:07 UTC 2018
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.
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.kinnear at oracle.com> wrote:
> David Holmes and I are good with Dan’s proposal here.
>> On Jan 9, 2018, at 5:27 PM, Dan Smith <daniel.smith at oracle.com <mailto:daniel.smith at oracle.com>> wrote:
>>> On Jan 3, 2018, at 9:16 AM, Karen Kinnear <karen.kinnear at oracle.com <mailto:karen.kinnear at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the valhalla-spec-experts