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.go...@oracle.com> > À: "daniel smith" <daniel.sm...@oracle.com>, "Daniel Heidinga" > <daniel_heidi...@ca.ibm.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@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_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
