Daniel (S), Brian,
i think your view on this subject is biased by the fact that you built that
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
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.
----- Mail original -----
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "daniel smith" <daniel.sm...@oracle.com>, "Daniel Heidinga"
> Cc: "valhalla-spec-experts" <firstname.lastname@example.org>
> 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_heidi...@ca.ibm.com>
>>>> 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
>> in which no metadata (Lookup, name, and type) gets passed. This allows any
>> method, field, or constructor to act as a bootstrap. In particular, it
>> 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
>> indicate the invocation style. The Lookup type indicates the traditional
>> 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