----- Mail original -----
> De: "daniel smith" <daniel.sm...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts@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 <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), 
>> 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


Reply via email to