lambda and MethodHandles in current prototype

[Brian Goetz]

And, keep in mind, this is a just a temporary strategy for the prototype; the real strategy (outlined in the JVMLS talk) is not yet implemented.  

On Nov 27, 2011, at 5:13 AM, Peter Levart wrote:

> On Monday, November 21, 2011 11:46:05 AM Maurizio Cimadamore wrote:
>> On 20/11/11 19:58, Peter Levart wrote:
>>> Has the compilation strategy changed? Aren't MethodHandles used any more or are they still, but the conversion to functional interfaces doesn't use MethodHandleProxies.asInterfaceInstance()? Are there any plans for the above code to print true/true (or at least false/true)?
>> Yes, the implementation has changed - the compiler used 
>> MethodHandleProxies.asInterfaceInstance for translating method 
>> references - a couple of weeks ago I cleaned up the compiler to support 
>> two different (and consistent) translation strategies:
>> 
>> *) by default, the compiler will generate anonymous inner class for 
>> lambdas/method references
>> 
>> *) optionally (if you use the -XDlambdaToMethod flag), the compiler will 
>> use 292, by passing method handles on to a fake BSM lambda metafactory 
>> that will spin the bytecode on the fly.
> 
> I see. 
> 
> I experimented with modified implementation of ProxyHelper.metaFactory and observed that the 2nd argument to
> 
> metaFactory(
>                                      MethodHandles.Lookup caller,
>                                      String invokedName,
>                                      MethodType invokedType,
>                                      Class<?> samClass,
>                                      MethodHandle handle
> )
> 
> is currently allways invoked with a constant String "lambda". Is this meant to be specified as the target method name or something similar that will facilitate serializability of SAM instances?
> 
> Regards, Peter
> 
>> 
>> So, the conclusion is that the compiler doesn't use 
>> MethodHandleProxies.asInterfaceInstance directly anymore - either it 
>> just emit an anonymous inner class, or it defers creation to a BSM which 
>> then could, in principle, use MethodHandleProxies.asInterfaceInstance or 
>> do some other fancy stuff to spin bytecode on the fly.
>> 
>> Maurizio
>> 
>