> On Apr 6, 2018, at 10:32 PM, John Rose <john.r.r...@oracle.com> wrote: > > Reviewed; it's good. >
Thanks. > The javadoc text doesn't need to predict the future; it just needs to document > the present specification. So the sentence that begins "This constraint > allows for > the future possibility…" is not really necessary. It's certainly not > normative. > Dan did some surgery on the package doc when doing the condy spec work. We both agreed that text here was generally non-normative where as the VM specification provides the normative text. I felt i could not leave the current situation dangling without some explanation, since it introduces an obvious difference between indy and condy leaving the reader wondering the benefit might be. I’ll update and preface with “Note: “ to make the distinction clearer. It does make me wonder whether we should proceed less conservatively and implement now the support condy invocation of BSMs without meta-data. Paul. > — John > > On Apr 6, 2018, at 5:15 PM, Paul Sandoz <paul.san...@oracle.com> wrote: >> >> Hi, >> >> Please review this patch to constrain constant dynamic bootstrap methods to >> methods whose first parameter type is MethodHandles.Lookup. >> >> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8199875-condy-bsm-lookup/webrev/ >> <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8199875-condy-bsm-lookup/webrev/> >> >> We are conservatively diverging from invoke dynamic bootstrap method >> invocation behaviour to possibly diverge further in the future and allow for >> constant dynamic bootstrap methods that are invoked without the >> lookup/name/type arguments. The change enables further divergence in a >> future release without breaking compatibility. >> >> This would make it easier to use existing methods as bootstrap methods >> rather than invoking via a level of indirection for explicit wrappers or >> using ConstantBootstraps.invoke. The experience garnered from prototyping >> language and low-level library features informs us this is useful. >> >> CSR is here: >> >> https://bugs.openjdk.java.net/browse/JDK-8201268 >> <https://bugs.openjdk.java.net/browse/JDK-8201268> >> >> Thanks, >> Paul. >
