groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: JDK8 Streams / Closure cast to interface
Date Wed, 23 Nov 2016 13:43:07 GMT
It sounds like a good idea to support Java lambda syntax, or at least provide a way in Groovy
to use Java lambdas. The only concern I have is that I still think the closure syntax is better,
since you don't have parenthesis overload, and I still like the curly braces to distinguish
that we are changing from a "parameter passing" context to an "expression" context. To be
the lambda single expression syntax looks too much like parameter passing rather than defining
a lambda.

stream.forEach((it) -> System.out.println(it))

stream.forEach{ System.out.println(it) }

I agree with Jochen about not having to create the Closure, if that is an option that sounds
great. At first I thought it would be an observable (and therefore potentially breaking) change
because the class would extend Closure, but then I realize when you pass a closure to a SAM
method, the getClass is a java.lang.reflect.Proxy subclass instance. I have a hard time thinking
that users would call Proxy.isProxyClass on the result, but who knows. But, I wonder if that
potential breakage is worth it if Groovy could replace the closure that does not escape with
a non-closure lambda (Java 8+) or non-closure inner class (Java 7 and earlier) when in static
compilation mode. Since we know that the closure is to be assigned to a non-Closure type,
we know setDelegate/setOwner can't be called, nor can setResolveStrategy. That situation should
enable the Groovy static compiler to know whether or not use of Closure is required.

I think it's possible only under static compiler, because in dynamic mode, the runtime type,
metaclass or runtime extension method could introduce an overload of the same method that
takes Closure. I think only the static compiler can guarantee that the closure can be replaced
with non-closure type without changing semantics (other than the change of getClass from proxy
to something else).


-----Original Message-----
From: Graeme Rocher [] 
Sent: Wednesday, November 23, 2016 6:18 AM
Subject: Re: JDK8 Streams / Closure cast to interface

Jochen said - “If you want this really efficient, you have to skip the generation of the
Groovy Closure instance. This is doable and I plan to do this, but it will be a breaking change
(all open blocks would be realised using the same class for example, having that instance
would even become optional).”

Could I recommend that since the new parser now supports the lambda syntax that we add to
Groovy the optimised version for lambdas and keep the closure behaviour as is to avoid a breaking

This would mean that there is a visual syntactical difference between closures and lambdas
and the behaviour of lambdas will be closer to Java thus not surprising folks coming from

We could then keep the behaviour of closures the same as it is now without it being a breaking


On Wed, Nov 23, 2016 at 11:11 AM, Jochen Theodorou <> wrote:
> On 22.11.2016 19:37, Winnebeck, Jason wrote:
>> I was referring to a compile-time generation of the class -- that the 
>> Closure itself that is normally generated implements the interface natively.
> Which means we are talking about direct assignments to local variables only?
> I mean the static compiler can do that in more cases, but frankly, why 
> should the static compiler even bother with creating a Closure?
>> That would make it equivalent to anonymous class in Java 7 and 
>> earlier for calling functional (or any SAM type) methods. That 
>> wouldn't have any problems on Android, and should be as efficient as Java without
> Android is ok, yes. As efficient as Java without lambdas... well.. 
> that I am not sure of. Even if you make it as an anonymous inner class 
> that implements the interface and extends Closure, even if the 
> interface method will just call doCall, you will still have to pay the 
> initialization cost of the Closure, and Closure will inspect itself to 
> set the maximum parameter number for example, you will still request a meta class and
do some other things.
> So the init would not be as efficient. The method invocation should be 
> similar to Java, if done from Java then, since there is no dynamic 
> call. So here you would gain over todays Closure.
> But for typical usages of non-static Groovy the gain would be almost nil.
> Unless we can lift restrictions
>> I would assume the interface's method delegating to doCall would get 
>> inlined. In other words, Groovy generating code like:
>> class X {
>>         public static void main(String[] args) {
>>                 Stream.of(1).forEach(new x__closure1(X.class, X.class));
>>         }
>>         private static class x__closure1 extends Closure<Void> 
>> implements Consumer<Integer> {
>>                 public x__closure1(Object owner, Object thisObject) {
>>                         super(owner, thisObject);
>>                 }
>>                 void doCall(Integer x) {
>>                         System.out.println(x);
>>                 }
>>                 @Override
>>                 public void accept(Integer x) {
>>                         doCall(x);
>>                 }
>>         }
>> }
>> From Groovy: Stream.of(1).forEach { println it }
>> The new part being that Groovy added the accept method and implements 
>> to the closure it already normally would have generated, and 
>> castToType would not need to be called. All of the code manipulation 
>> is done at compile-time so it is fully STC and Android compatible, 
>> and no reflection is in use. You still have the a little more 
>> overhead of Closure object compared to Java static inner class, but I 
>> imagine this must be a lot less than proxy, but still allows Closure 
>> to use the owner/delegate patterns that Groovy is known for, and I 
>> assume would not affect backwards compatibility as superclass stays Closure.
>> Of course, if it were possible for compiler to determine that the 
>> closure is never using owner, delegate, or "thisObject", then it 
>> could be possible to drop the "extends Closure" entirely if it can be 
>> proven that the "closureness" of the object can never be observed. 
>> But that's likely not possible as any method taking an interface 
>> could choose to check for instanceof Closure and/or cast or do 
>> something special if Groovy closure is passed in -- although is that 
>> even possible today since Groovy actually passes in a proxy?
> It depends on if the implicit "this" is used or not. { println it } 
> uses implicit this, thus cannot do it for sure. { this.println it }, 
> no implicit, thus can be optimized.
> I am wondering what would happen if we had 2 versions, one with 
> implicit this delegation logic, the other not. Because if the usage is 
> just an appended block and the target is just a functional interface, 
> you will not need the version with delegate.
> bye Jochen

Graeme Rocher

This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.
View raw message