CONSTANT_Dynamic bootstrap signature restriction

[Dan Smith]

> On Mar 7, 2018, at 3:51 PM, forax at univ-mlv.fr wrote:
> 
> ----- Mail original -----
>> De: "daniel smith" <daniel.smith at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
>> Envoyé: Mercredi 7 Mars 2018 22:52:32
>> Objet: Re: CONSTANT_Dynamic bootstrap signature restriction
> 
>>> On Mar 7, 2018, at 7:48 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>>> This might not pan out, and if so we can drop the error check and return to
>>>> where we were.
>>>> But it seems promising, and we don't want to get stuck in 11 making
>>>> compatibility promises
>>>> about the interpretation of things like 'bootstrap(Object... args)'.
>>> 
>>> I think it's too late for that, once we had said that the bsm is called with
>>> methodhandle.invoke (or more recently invokeWithArguments), bootstrap(Object...
>>> args) is already a valid construct.
>> 
>> The proposed rule detects a CONSTANT_Dynamic bootstrap of this form and rejects
>> it, because the first parameter's type is not Lookup. This is an explicit
>> check, not a side-effect of invokeWithArguments.
> 
> My point is that you can do that for Condy but not for Indy because Indy is already specified in term of invokeWithArguments.
> And i think everybody in the EG that has to maintain a VM implementation will agree with me that it's better to have Indy and Condy semantics to be aligned.

You have correctly identified the trade-off: ease of use for condy (in the future, if we decide to pursue it) vs. consistency with indy.

Our claim is that it is *possible* that the inconsistency will be worth it. If not, we can drop the restriction and make things consistent again.

FWIW, another goal is to move most of this logic into an API, so that it will no longer be a matter for VM implementations (and specifications!) to have to worry about.

—Dan