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


Reply via email to