It's two problems in one. A) The code generation itself is not quite so bad as you might think, especially if we for a moment ignore serializable lambdas. For instance, here's how Eclipse's JDT does it: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/LambdaExpression.java#n178 <http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/LambdaExpression.java#n178>
It's a matter of recording a bootstrap method in the constant pool of the class, and then emitting a invokeDynamic to "hit" that bootstrap method. B) The really tricky issue is the type analysis you need to have in place to figure out the type signature of the Lambdas type signature and implementation method. Both javac and ECJ grew significantly in complexity in working to find this out, including backtracking. The choice of the lambda's type will in turn affect which possible overload to call. Only the static compilation will have a chance to do this right, and getting it "perfect" (including variable and member capture) is pretty tricky. -Jesper > On 22 Aug 2017, at 12.11, Paul King <[email protected]> wrote: > > It's on my TODO list too! But it's a long list! :-) > > Paul. > > > On Tue, Aug 22, 2017 at 6:58 PM, Daniel Sun <[email protected] > <mailto:[email protected]>> wrote: > Hi Paul, > > As to the native lambdas, it is always on my TODO list. I wish I had > enough time to study how to generate bytecode for it... > > Cheers, > Daniel.Sun > > > > -- > View this message in context: > http://groovy.329449.n5.nabble.com/VOTE-Release-Apache-Groovy-2-6-0-alpha-1-tp5742698p5742735.html > > <http://groovy.329449.n5.nabble.com/VOTE-Release-Apache-Groovy-2-6-0-alpha-1-tp5742698p5742735.html> > Sent from the Groovy Dev mailing list archive at Nabble.com. >
