You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Russel Winder <ru...@winder.org.uk> on 2018/05/27 10:45:19 UTC
Groovy 3 release
Hi,
How much of:
http://www.javamagazine.mozaicreader.com/MarApr2018/Twitter#&pageSet=61&page=0
is already in place with tests? Does this define the point at which 3.0.0 gets
released and everything else gets punted to 4.0.0?
--
Russel.
==========================================
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Road m: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
Re: Groovy 3 release
Posted by Jesper Steen Møller <je...@selskabet.org>.
> On 27 May 2018, at 20.25, Jesper Steen Møller <je...@selskabet.org> wrote:
>
> On 27 May 2018, at 14.44, Daniel.Sun <su...@apache.org> wrote:
>>
>> Native lambda is only available on master branch, and it is only be enabled
>> under static compilation.
>>
>
> I had a chance to examine the current implementation. It uses a LambdaMetafactory to bootstrap (i.e. generate inner class) access to the doCall of the generated lambda/closure object. That means TWO classes per lambda definition (in use), and two objects generated at every lambda use. I haven't made any benchmarks, but we should be able to do better:
> 1) Don't distinguish between lambdas and closures.
> 2) If the closure's instantiation is targeting a functional interface, add the expected identified functional interface to the closure class, and implement that in the closure class (bridging the single interface method into the doClass) call.
> 3) If using compilestatic, we don't need any type conversions to match the callee.
4) Added bonus: Even if using dynamic, sometimes we may use our "invested" bridge method so we could avoid creating a proxy.
After all, even a lot of dynamic Groovy ends up calling something which is well known in advance.
-Jesper
Re: Groovy 3 release
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Jesper,
> 1) Don't distinguish between lambdas and closures.
It's better to implement closure from scratch through native lambda,
which is slim and has better performance. But closure is so versatile that
we can reference its owner and delegate to implement complex DSL(e.g.
gradle's DSL, which contains a lot of nested closures), so this task is not
trivial.
If you would like to contribute this area, that would be great!
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Groovy 3 release
Posted by Jesper Steen Møller <je...@selskabet.org>.
On 27 May 2018, at 14.44, Daniel.Sun <su...@apache.org> wrote:
>
> Native lambda is only available on master branch, and it is only be enabled
> under static compilation.
>
I had a chance to examine the current implementation. It uses a LambdaMetafactory to bootstrap (i.e. generate inner class) access to the doCall of the generated lambda/closure object. That means TWO classes per lambda definition (in use), and two objects generated at every lambda use. I haven't made any benchmarks, but we should be able to do better:
1) Don't distinguish between lambdas and closures.
2) If the closure's instantiation is targeting a functional interface, add the expected identified functional interface to the closure class, and implement that in the closure class (bridging the single interface method into the doClass) call.
3) If using compilestatic, we don't need any type conversions to match the callee.
-Jesper
Re: Groovy 3 release
Posted by "Daniel.Sun" <su...@apache.org>.
Native lambda is only available on master branch, and it is only be enabled
under static compilation.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Groovy 3 release
Posted by Jesper Steen Møller <je...@selskabet.org>.
> On 27 May 2018, at 13.37, Daniel.Sun <su...@apache.org> wrote:
>
>> 3) Java lambdas compile into Closures, which do not directly support
> functional interfaces (so, in the examples shown for streams, proxies are
> made)
>
> Groovy's lambda will be compiled into native lambda when static compilation
> is enabled ;-)
>
Oh, I thought that was still on a branch?
I mean, it doesn't always work, does it?
-Jesper
Re: Groovy 3 release
Posted by "Daniel.Sun" <su...@apache.org>.
> 3) Java lambdas compile into Closures, which do not directly support
functional interfaces (so, in the examples shown for streams, proxies are
made)
Groovy's lambda will be compiled into native lambda when static compilation
is enabled ;-)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Groovy 3 release
Posted by Jesper Steen Møller <je...@selskabet.org>.
All of it is master with tests at the moment, as far as I've seen.
There are a couple of caveats:
1) The default interfaces are implemented using traits, not as actual default methods on interfaces.
2) Method and constructor references are implemented as closures.
3) Java lambdas compile into Closures, which do not directly support functional interfaces (so, in the examples shown for streams, proxies are made)
For 3: I'm currently working on a proposal to keep the closure semantics as they are, but also implementing the intended interfaces and adding the necessary bridge method. This would probably only work with static compilation, or at least some static assumptions.
-Jesper
> On 27 May 2018, at 12.45, Russel Winder <ru...@winder.org.uk> wrote:
>
> Hi,
>
> How much of:
>
> http://www.javamagazine.mozaicreader.com/MarApr2018/Twitter#&pageSet=61&page=0
>
> is already in place with tests? Does this define the point at which 3.0.0 gets
> released and everything else gets punted to 4.0.0?
>
> --
> Russel.
> ==========================================
> Dr Russel Winder t: +44 20 7585 2200
> 41 Buckmaster Road m: +44 7770 465 077
> London SW11 1EN, UK w: www.russel.org.uk