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