----- Mail original -----
> De: "daniel smith" <daniel.sm...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "valhalla-spec-experts" <firstname.lastname@example.org>
> 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 <fo...@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),
>> args) is already a valid construct.
> The proposed rule detects a CONSTANT_Dynamic bootstrap of this form and
> 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
> 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.