lambda and MethodHandles in current prototype

[Rémi Forax]

On 11/27/2011 11: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?

Hi Peter,
good question !

The name of the handle (which is opaque for you but not for the VM)
is enough to make the lambda serializable.

The calling name has to be provided to be compliant with JSR 292,
but is not used at all currently.

>
> Regards, Peter

Rémi