groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: Groovy 3.0 Java Lambda
Date Tue, 03 Apr 2018 22:03:17 GMT
On 03.04.2018 19:17, mg wrote:
> With regards to Groovy 3.0 Java lambda support: Is it practically doable 
> to turn a Groovy closure into a Groovy Java lambda if only effectively 
> final variables are used inside the closure ? And if yes, might that be 
> a future Groovy feature ?

My idea is to have a simple Closure object that has the required 
information plus a handle for the method implementation(s) and that this 
can be used internally with a special callsite to implement the usage of 
the delegate and the resolution strategy. That means we my not be able 
to use a lambda factory for this, but well, the implementation would be 
similar to normal Java lambdas. Similar enough to be able to use the 
exact same mechanism as lambdas in some cases. I think with a bit 
thinking we would arrive at a more universal mechanism usable for 
both... but maybe not with LambdaFactory like Java does.

> I am asking because otherwise there will exist two quite different 
> anonymous function syntax varieties in Groovy, with both most likely 
> being in active use, instead of one just existing for Java syntax 
> compatibility reasons. Which of course works, but feels a bit messy / 
> un-Groovy, and also can lead to code being executed slower than 
> possible, if someone uses Groovy closure syntax everywhere.

I think most cases of lambdas are operating on data they get. We could 
define a closure like interface for these and convert a normal Closures 
falling under that category to this new SAM Closure interface instead.

> Or would "closure inlining" support be the better approach here (also 
> with regard to implementation effort), since turning e.g. a forEach + 
> cls expression into a for-loop with the cls inlined as a block should be 
> even faster than using a Java lambda ?

I see what I described above actually as a required step for that kind 
of inlining. You need that to be able to handle the pseudo Closures you 
still require to handle strategies and special callsites. But I see it 

bye Jochen

View raw message