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.


> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

mlvm-dev mailing list

Reply via email to