Implementing VarHandle

[Paul Sandoz]

On Apr 20, 2015, at 4:40 PM, Remi Forax <forax at 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.levart at 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 at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20150420/4a0a823d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20150420/4a0a823d/signature.asc>