On Apr 20, 2015, at 4:40 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > On 04/20/2015 11:06 AM, Paul Sandoz wrote: >> Hi Peter, >> >> We did consider supporting field and method literals in 9, leveraging the >> same syntax as for method references combined with target typing. But, we >> have currently concluded it would be best to punt it to post-9. >> >> As a result there is currently no compelling need to support VarHandles in >> the constant pool, which, while not particular hard AFAICT (famous last >> words!), is a welcome reduction in work. >> >> Paul. > > You don't even need to have VarHandle in the constant pool, > once you have invokedynamic, you can create any constant you want at runtime,
Yes, good point (ignoring pesky bootstrap issues with CHM etc). When we were pondering field/method literals we also pondered about the translation to byte code, and naturally indy came up. This led onto whether "constant dynamic" (John's idea and term), a derived form of indy for constants, might be worth investigating. Paul. > MethodHandles are in the constant pool only because you need it to reference > the bootstrap method of an invokedynamic, you need it to bootstrap > invokedynamic if you prefer. > > That's not fully true because we may also want to have a way to represent > constant fields in annotation. > This give me an idea, invokedynamic should be used to specify the constant > values in annotation. > It will be extensible for the JDK and any (dynamic) languages that have a > more powerful annotation mechanism > (Groovy anyone?) will be able to leverage that. > > At runtime, an annotation will still be a proxy but instead of using > java.lang.reflect.Proxy, > it should use the Proxy2 API [1] :) > > Rémi > [1] https://github.com/forax/proxy2 > > >> >> On Apr 20, 2015, at 10:41 AM, Peter Levart <peter.lev...@gmail.com> wrote: >>>> The thing that pushed us over the edge is that value types are coming. >>>> With value types, one can create type-safe, zero-cost, specialized >>>> wrappers for {Static,Instance,Array,Native}VarHandle<T> that wrap an >>>> underlying VH; because these wrappers can be values, they can provide type >>>> safety with no indirection or footprint costs. So it seemed better to >>>> provide a simple, clean, low-level API now that doesn’t make any >>>> assumptions, let the early adopters (mostly us) deal with the fact that >>>> type safety comes at runtime (just as with MHs), and later provide a clean >>>> set of value wrappers on top of it. >>> This seems like a good plan for post-JDK9 times. But I still miss one thing >>> in this picture - the syntax. If purely API approach is taken, then we will >>> still be using Strings to identify fields and do the caching of VarHandles >>> ourselves. Are there any plans for specifying syntax for constant >>> [Method|Var] handles in Java or is this being reserved for post-JDK9 times >>> where the syntax will be used to produce type-safe wrappers (similar to >>> approach taken with MethodHandles vs. Lambdas)? >>> >>> Regards, Peter >>> >>> >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev@openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
