CONSTANT_Dynamic bootstrap signature restriction

forax at forax at
Wed Mar 7 22:51:46 UTC 2018

----- Mail original -----
> De: "daniel smith" <daniel.smith at>
> À: "Remi Forax" <forax at>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at>
> 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> 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.

> In a plausible future (one that we want to make space for), rather than
> reporting an error, CONSTANT_Dynamic resolution will notice the lack of Lookup
> as a first parameter, and so pass an argument array to invokeWithArguments that
> doesn't contain the Lookup, name, or type.

If the first arguments of a BSM is an Object and not a Lookup, it's not an error, unlike a classical Java call, a bsm call is linked dynamically so the signature of a bsm do not have to exactly match with its calling arguments.

> —Dan


More information about the valhalla-spec-observers mailing list