CONSTANT_Dynamic bootstrap signature restriction

[Remi Forax]

Daniel (S), Brian,
i think your view on this subject is biased by the fact that you built that library.

While the name and the type of a condy are not strictly necessary because if you have one bsm by constant, you know the type, you still need the lookup argument, apart if you are building a library that only construct constants that are in the same module than their bsms. Once you have user defined methods/constructors to call to construct the constant, you can not skip the lookup parameter. 

And i will re-use the argument than Brian use rightly about java.lang.invoke, not a lot of people will write BSMs, so modifying an already complex API call (callsite info * lazy loading of constants * conversion of bsm arguments * varargs) to take care of hiding potentially unused arguments only for few users does not worth the added complexity.  

> 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. 

regards,
Rémi

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "daniel smith" <daniel.smith at oracle.com>, "Daniel Heidinga" <Daniel_Heidinga at ca.ibm.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mardi 6 Mars 2018 22:34:13
> Objet: Re: CONSTANT_Dynamic bootstrap signature restriction

> To add to this; we've been building a library which makes extensive use
> of condy, and we've found that we have to write many factory methods two
> ways, one as an ordinary factory method and one as a bootstrap which
> generally just calls the regular factory.  It would reduce duplication
> both in the library and in the classfile to allow an ordinary factory
> method to be used as a bootstrap, if you don't care about the metadata
> parameters (lookup, name, type.)  Turns out this condition is quite
> common for abstractions that want to support self-condyization.
> 
> On 3/5/2018 7:09 PM, Dan Smith wrote:
>>> On Mar 5, 2018, at 12:56 PM, Daniel Heidinga <Daniel_Heidinga at ca.ibm.com> wrote:
>>>> In discussions about future directions for CONSTANT_Dynamic, we've
>>>> decided it would be helpful to restrict the set of legal bootstrap
>>>> signatures. The first parameter type would be required to be declared
>>>> with type MethodHandles.Lookup.
>>> Dan, can you expand on why this restriction is helpful? It helps when
>>> evaluating a specification to have the rationale for the changes - both
>>> for the EG and the observers.
>> We're considering, for the future, an alternative style of bootstrap invocation
>> in which no metadata (Lookup, name, and type) gets passed. This allows any old
>> method, field, or constructor to act as a bootstrap. In particular, it provides
>> a clean way to map from a live object to a constructor/factory call that will
>> create the object, without having to write dedicated bootstrap code.
>>
>> The idea is that the first parameter type of the method handle acts as a key to
>> indicate the invocation style. The Lookup type indicates the traditional style.
>>
>> 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)'.
>>
> > —Dan