RSVP please: Re: Nestmates JVMS changes to selection and behavior implications

Doug Lea dl at
Mon Jan 15 23:55:51 UTC 2018

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...


> thanks,
> Karen
> p.s. changes are relative
> to:
>> On Jan 10, 2018, at 9:34 AM, Karen Kinnear <karen.kinnear at
>> <mailto:karen.kinnear at>> 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.smith at
>>> <mailto:daniel.smith at>> wrote:
>>>> On Jan 3, 2018, at 9:16 AM, Karen Kinnear <karen.kinnear at
>>>> <mailto:karen.kinnear at>> 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

More information about the valhalla-spec-observers mailing list