groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <fo...@univ-mlv.fr>
Subject Re: About the native lambda
Date Fri, 22 Dec 2017 11:53:05 GMT
> De: "Jesper Steen Møller" <jesper@selskabet.org>
> À: "dev" <dev@groovy.apache.org>
> Cc: dev@groovy.incubator.apache.org
> Envoyé: Vendredi 22 Décembre 2017 11:26:06
> Objet: Re: About the native lambda

>> On 22 Dec 2017, at 10.48, Daniel.Sun < [ mailto:sunlan@apache.org |
>> sunlan@apache.org ] > wrote:

>> The problem I am trying to resolve is how to get the method's name
>> and descriptor? [2] It seems the type flow analysis have to rely on the
>> existing static compilation...

> There is no short cut possible here: You need full static analysis to make
> lambdas Java-compatible and emit the right invokedynamic calls. And the type
> inference is really complicated w.r.t overloads.

> You can read about it here: [
> http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/F.html |
> http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/F.html ]

> -Jesper

There is a "shortcut" possible, like usually with a dynamic language, you can postpone the
creation until you have enough data. 

So you create a lambda object but not by emiting the invokedynamic on the LambdaMetaFactory,
but by creating a new Lambda object (it can be the same object as a Closure or not) and when
you need to coerce it to a functional interface at that time you call the invokedynamic on
the LambdaMetaFactory. 

To be able to call the LambdaMetaFactory, the Lambda object need to store a MethodHandle on
a static method (a constant method handle) and the Lookup object used to create the method
handle. 

cheers, 
Rémi 

Mime
View raw message