----- Mail original ----- > De: "daniel smith" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "valhalla-spec-experts" <[email protected]> > 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 <[email protected]> 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 Rémi
