CONSTANT_Dynamic bootstrap signature restriction

[Brian Goetz]

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