You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Jesper Steen Møller <je...@selskabet.org> on 2018/05/17 23:59:23 UTC
Proposed Groovy 3.0 Scope
Groovy 3.0 Scope (suggestion)
TL;DR: I want to help develop Groovy 3.0, but I'm not sure how: It appears that there's little consensus around priorities and scope. I'm suggesting a structure for discussing scope and setting priorities. HTH.
Introduction
Several strands of Groovy development are going on at the moment, with different focus - and in the eyes of a would-be contributor, it’s difficult to find the best place to help. So, I’ve taken a step back and tried to get an overview.
This is my proposed laundry list of possible items for Groovy 3.0. It has been compiled by watching the dev-list, watching the Java development (8, 9, 10, 11…), reading blog posts and being a Groovy and Grails application developer since 2012, and listening to the input offered.
At the outset, it follows the discussion from the Apache Groovy Roadmap <http://mail-archives.apache.org/mod_mbox/groovy-dev/201701.mbox/%3cCADQzvmn0A83TeNeg2OP_aBMGNAORuHxduLvD7t+nPun-VTDmfQ@mail.gmail.com%3e> thread on the mailing list (from January 2017!)
I do know that several items are controversial, and I’m not trying to tip the scale in any direction. This is just a strawman, we’ll discuss it from here.
Motivation for Groovy 3.0
It’s 2018: Java is alive again, and Groovy is no longer “ahead but compatible”, rather the opposite. We need to address Java 9+ compatibility, leverage and augment features in Java 8+, and support newer deployment modes, such as lean microservice deployments - and be able to be deployed under JPMS.
Compatibility Goals
Groovy 3.0 is a breaking change from Groovy 2.x, as it will require Java 8 or better. There should be no gratuitous incompatibilities, but some are required:
A new MOP would likely break compatibility when calling Groovy 3-compiled code from a Groovy 2 runtime.
A new MOP could be made compatible when calling Groovy 2-conpiled code from a Groovy 3 runtime.
A new package structure would break compatibility. Adding the new classes as fronts for the old classes (and deprecating those) could help people writing for 2.x, like it is being done right now for CliBuilder.
I’ve broken the plan into a number of “themes”, in no particular order. The idea is to put these into epics in JIRA, and attach individual tasks to those.
Themes
Fit into Java Platform Module System
Avoid discontinued JDK calls (i.e. reflection tricks)
Leaner Closures (like native lambdas)
Cleanup the MOP
Improve “copy’n’paste-compatibility” with Java
These are expanded in the following sections.
Breakdown of Development Themes
Theme: Fit into Java Platform Module System
Chop Groovy up into core and a set of extension modules - and change package names accordingly. Perhaps we should even divide into a runtime-only and compiler split, to allow for even smaller runtimes.
If we provide “bridge-APIs” in Groovy 2.x in the new package names, we could even allow for compatible code to be written i Groovy 2.5+ which would upgrade seamlessy to the Groovy 3 implementation.
Theme: Avoid discontinued JDK calls (i.e. reflection tricks)
I actually thought it was worse, but Groovy only uses Unsafe for FastStringUtils in the groovy-json-direct subproject.
We use “illegal” reflection tricks a lot and should migrate this to using method handles, as these have been promised to become really illegal in future JVM versions.
Theme: Leaner Closures (native lambdas)
There has been a lot of discussion around this, but I fear it’s been going in circles:
Groovy’s closures are implemented as (generated) classes, whereas Java’s lambdas are implemented in methods. I’m thinking it should be possible to make Groovy’s closures leaner by using the same approach as Javas lambdas, but without sacrificing the unique features of closures in Groovy, AND still retaining their unique features, such as delegation.
Finally, there was some consideration as to how things are done in Painless: http://groovy.329449.n5.nabble.com/new-MOP-under-Java9-module-system-findings-td5749016.html#a5749042 <http://groovy.329449.n5.nabble.com/new-MOP-under-Java9-module-system-findings-td5749016.html#a5749042>
This need not be tied to the syntax and semantics of Java lambdas, at all. See below for the discussion.
Theme: Indy by default / New MOP
See the discussion http://groovy.markmail.org/thread/yxeflplf5sr2wfqp <http://groovy.markmail.org/thread/yxeflplf5sr2wfqp>
This depends on whether or not we want to provide binary compatibility.
Jochen did work on the new MOP a while ago, present in a branch in the repo, as presented here: https://www.slideshare.net/gr8conf/groovy-3-and-the-new-mop-in-examples <https://www.slideshare.net/gr8conf/groovy-3-and-the-new-mop-in-examples>
There’s also a blog post here: http://blackdragsview.blogspot.dk/2015/03/thoughts-about-new-meta-class-system.html <http://blackdragsview.blogspot.dk/2015/03/thoughts-about-new-meta-class-system.html>
I’m thinking it makes a lot of sense, but I guess it needs to be broken down into bite size tasks.
(See also link above around Painless for some MOP discussion)
Theme: Improve “copy’n’paste-compatibility” with Java
The original Java compatibility has been a nice gateway drug for Groovy beginners, and is worth considering in a number of cases:
Try with resources - Partially done - needs doco changes
Raw strings - Spiking stage (see GROOVY-8564)
Array initialization - Partially done - needs doco changes
Lambda syntax for closures - Done-ish? (native lambda is enabled only in the static mode for the time being - that is possibly final design). Or we
‘var’? (alias for `def` with some limitation, only used to declare variable) added in GROOVY-8498, but see GROOVY-8580 and GROOVY-8582.
Method/constructor references - possible in Java syntax, but needs to more lean (AKA native method reference) and needs doco
Default methods in interfaces - done using traits but we should consider native support and we need doco (can’t be called from Java, then, can they?)
Static method in interfaces - TBD
Improved switch syntax changes: might possibly be relevant before 3.0 is released (see GROOVY-8584)
Be aware, this subject is really divisive: Some feel that Java compatibility should be a default, others that Groovy’s constructs are much more expressive and succinct.
It has also been suggested Java features added for compatibility should be accompanied by a “unidiomatic Groovy”-warning.
Next steps
Decisions, that only the committers can really make:
Did I forget anything?
Are these themes relevant?
Should some be deferred?
So, should be have the discussions now, or defer tem to when/if somebody has implemented them?
Thanks for reading.
You can find the document at: https://docs.google.com/document/d/1gb0jLqQWOOkcqzlO25Af8dplQzq85qabNgpmC1vyBeg/edit?ts=5af9a2d4#heading=h.avsaw5h501ly
Kind regards,
Jesper
Re: Proposed Groovy 3.0 Scope
Posted by "Daniel.Sun" <su...@apache.org>.
groovysh does not support the new parser for the time being.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Proposed Groovy 3.0 Scope
Posted by Jesper Steen Møller <je...@selskabet.org>.
> On 22 May 2018, at 10.35, Paul King <pa...@asert.com.au> wrote:
>
> Nice list. The other thing worth adding somewhere is toolchain support for the new Parser.
> Tools like Groovydoc is needed I would say. We have some additional tools, e.g. like Java2Groovy and others which we could then consider.
>
Oh, I didn't know that -- that should be on the list as well. I'm expecting that the old parser would be completely removed for Groovy 3.0, or -- if people depend on it -- as an add-on module.
-Jesper
Re: Proposed Groovy 3.0 Scope
Posted by Paul King <pa...@asert.com.au>.
Nice list. The other thing worth adding somewhere is toolchain support for
the new Parser.
Tools like Groovydoc is needed I would say. We have some additional tools,
e.g. like Java2Groovy and others which we could then consider.
Cheers, Paul.
On Fri, May 18, 2018 at 9:59 AM, Jesper Steen Møller <je...@selskabet.org>
wrote:
> *Groovy 3.0 Scope (suggestion)*
> TL;DR: I want to help develop Groovy 3.0, but I'm not sure how: It appears
> that there's little consensus around priorities and scope. I'm suggesting a
> structure for discussing scope and setting priorities. HTH.
> Introduction
> Several strands of Groovy development are going on at the moment, with
> different focus - and in the eyes of a would-be contributor, it’s difficult
> to find the best place to help. So, I’ve taken a step back and tried to get
> an overview.
>
> This is my proposed laundry list of possible items for Groovy 3.0. It has
> been compiled by watching the dev-list, watching the Java development (8,
> 9, 10, 11…), reading blog posts and being a Groovy and Grails application
> developer since 2012, and listening to the input offered.
>
> At the outset, it follows the discussion from the Apache Groovy Roadmap
> <http://mail-archives.apache.org/mod_mbox/groovy-dev/201701.mbox/%3cCADQzvmn0A83TeNeg2OP_aBMGNAORuHxduLvD7t+nPun-VTDmfQ@mail.gmail.com%3e>
> thread on the mailing list (from January 2017!)
>
> I do know that several items are controversial, and I’m not trying to tip
> the scale in any direction. This is just a strawman, we’ll discuss it from
> here.
> Motivation for Groovy 3.0
> It’s 2018: Java is alive again, and Groovy is no longer “ahead but
> compatible”, rather the opposite. We need to address Java 9+ compatibility,
> leverage and augment features in Java 8+, and support newer deployment
> modes, such as lean microservice deployments - and be able to be deployed
> under JPMS.
> Compatibility Goals
> Groovy 3.0 is a breaking change from Groovy 2.x, as it will require Java 8
> or better. There should be no gratuitous incompatibilities, but some are
> required:
>
> - A new MOP would likely break compatibility when calling Groovy
> 3-compiled code from a Groovy 2 runtime.
> - A new MOP could be made compatible when calling Groovy 2-conpiled
> code from a Groovy 3 runtime.
> - A new package structure would break compatibility. Adding the new
> classes as fronts for the old classes (and deprecating those) could help
> people writing for 2.x, like it is being done right now for CliBuilder.
>
>
> I’ve broken the plan into a number of “themes”, in no particular order.
> The idea is to put these into epics in JIRA, and attach individual tasks to
> those.
> Themes
>
> - Fit into Java Platform Module System
> - Avoid discontinued JDK calls (i.e. reflection tricks)
> - Leaner Closures (like native lambdas)
> - Cleanup the MOP
> - Improve “copy’n’paste-compatibility” with Java
>
>
> These are expanded in the following sections.
> Breakdown of Development ThemesTheme: Fit into Java Platform Module System
> Chop Groovy up into core and a set of extension modules - and change
> package names accordingly. Perhaps we should even divide into a
> runtime-only and compiler split, to allow for even smaller runtimes.
>
> If we provide “bridge-APIs” in Groovy 2.x in the new package names, we
> could even allow for compatible code to be written i Groovy 2.5+ which
> would upgrade seamlessy to the Groovy 3 implementation.
> Theme: Avoid discontinued JDK calls (i.e. reflection tricks)
> I actually thought it was worse, but Groovy only uses Unsafe for
> FastStringUtils in the groovy-json-direct subproject.
>
> We use “illegal” reflection tricks a lot and should migrate this to using
> method handles, as these have been promised to become really illegal in
> future JVM versions.
> Theme: Leaner Closures (native lambdas)
> There has been a lot of discussion around this, but I fear it’s been going
> in circles:
> Groovy’s closures are implemented as (generated) classes, whereas Java’s
> lambdas are implemented in methods. I’m thinking it should be possible to
> make Groovy’s closures leaner by using the same approach as Javas lambdas,
> but without sacrificing the unique features of closures in Groovy, AND
> still retaining their unique features, such as delegation.
>
> Finally, there was some consideration as to how things are done in
> Painless: http://groovy.329449.n5.nabble.com/new-MOP-under-
> Java9-module-system-findings-td5749016.html#a5749042
>
> This need not be tied to the syntax and semantics of Java lambdas, at all.
> See below for the discussion.
> Theme: Indy by default / New MOP
> See the discussion http://groovy.markmail.org/thread/yxeflplf5sr2wfqp
> This depends on whether or not we want to provide binary compatibility.
>
> Jochen did work on the new MOP a while ago, present in a branch in the
> repo, as presented here: https://www.slideshare.net/
> gr8conf/groovy-3-and-the-new-mop-in-examples
> There’s also a blog post here: http://blackdragsview.
> blogspot.dk/2015/03/thoughts-about-new-meta-class-system.html
> I’m thinking it makes a lot of sense, but I guess it needs to be broken
> down into bite size tasks.
> (See also link above around Painless for some MOP discussion)
> Theme: Improve “copy’n’paste-compatibility” with Java
> The original Java compatibility has been a nice gateway drug for Groovy
> beginners, and is worth considering in a number of cases:
>
> - Try with resources - Partially done - needs doco changes
> - Raw strings - Spiking stage (see GROOVY-8564)
> - Array initialization - Partially done - needs doco changes
> - Lambda syntax for closures - Done-ish? (native lambda is enabled
> only in the static mode for the time being - that is possibly final
> design). Or we
> - ‘var’? (alias for `def` with some limitation, only used to declare
> variable) added in GROOVY-8498, but see GROOVY-8580 and GROOVY-8582.
> - Method/constructor references - possible in Java syntax, but needs
> to more lean (AKA native method reference) and needs doco
> - Default methods in interfaces - done using traits but we should
> consider native support and we need doco (can’t be called from Java, then,
> can they?)
> - Static method in interfaces - TBD
> - Improved switch syntax changes: might possibly be relevant before
> 3.0 is released (see GROOVY-8584)
>
> Be aware, this subject is really divisive: Some feel that Java
> compatibility should be a default, others that Groovy’s constructs are much
> more expressive and succinct.
> It has also been suggested Java features added for compatibility should be
> accompanied by a “unidiomatic Groovy”-warning.
> Next steps
> Decisions, that only the committers can really make:
>
> 1. Did I forget anything?
> 2. Are these themes relevant?
> 3. Should some be deferred?
> 4. So, should be have the discussions now, or defer tem to when/if
> somebody has implemented them?
>
>
>
> Thanks for reading.
>
> You can find the document at: https://docs.google.com/document/d/
> 1gb0jLqQWOOkcqzlO25Af8dplQzq85qabNgpmC1vyBeg/edit?ts=5af9a2d4#heading=h.
> avsaw5h501ly
>
> Kind regards,
> Jesper
>
>
Re: Proposed Groovy 3.0 Scope
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
From the peanut gallery (top posting as we do here on peanut gallery ;-))
This is a GREAT list of things to do in Groovy 3.0!
Thanks,
Roman.
On Thu, May 17, 2018 at 4:59 PM, Jesper Steen Møller
<je...@selskabet.org> wrote:
> Groovy 3.0 Scope (suggestion)
>
> TL;DR: I want to help develop Groovy 3.0, but I'm not sure how: It appears
> that there's little consensus around priorities and scope. I'm suggesting a
> structure for discussing scope and setting priorities. HTH.
>
> Introduction
>
> Several strands of Groovy development are going on at the moment, with
> different focus - and in the eyes of a would-be contributor, it’s difficult
> to find the best place to help. So, I’ve taken a step back and tried to get
> an overview.
>
> This is my proposed laundry list of possible items for Groovy 3.0. It has
> been compiled by watching the dev-list, watching the Java development (8, 9,
> 10, 11…), reading blog posts and being a Groovy and Grails application
> developer since 2012, and listening to the input offered.
>
> At the outset, it follows the discussion from the Apache Groovy Roadmap
> thread on the mailing list (from January 2017!)
>
> I do know that several items are controversial, and I’m not trying to tip
> the scale in any direction. This is just a strawman, we’ll discuss it from
> here.
>
> Motivation for Groovy 3.0
>
> It’s 2018: Java is alive again, and Groovy is no longer “ahead but
> compatible”, rather the opposite. We need to address Java 9+ compatibility,
> leverage and augment features in Java 8+, and support newer deployment
> modes, such as lean microservice deployments - and be able to be deployed
> under JPMS.
>
> Compatibility Goals
>
> Groovy 3.0 is a breaking change from Groovy 2.x, as it will require Java 8
> or better. There should be no gratuitous incompatibilities, but some are
> required:
>
> A new MOP would likely break compatibility when calling Groovy 3-compiled
> code from a Groovy 2 runtime.
> A new MOP could be made compatible when calling Groovy 2-conpiled code from
> a Groovy 3 runtime.
> A new package structure would break compatibility. Adding the new classes as
> fronts for the old classes (and deprecating those) could help people writing
> for 2.x, like it is being done right now for CliBuilder.
>
>
> I’ve broken the plan into a number of “themes”, in no particular order. The
> idea is to put these into epics in JIRA, and attach individual tasks to
> those.
>
> Themes
>
> Fit into Java Platform Module System
> Avoid discontinued JDK calls (i.e. reflection tricks)
> Leaner Closures (like native lambdas)
> Cleanup the MOP
> Improve “copy’n’paste-compatibility” with Java
>
>
> These are expanded in the following sections.
>
> Breakdown of Development Themes
>
> Theme: Fit into Java Platform Module System
>
> Chop Groovy up into core and a set of extension modules - and change package
> names accordingly. Perhaps we should even divide into a runtime-only and
> compiler split, to allow for even smaller runtimes.
>
> If we provide “bridge-APIs” in Groovy 2.x in the new package names, we could
> even allow for compatible code to be written i Groovy 2.5+ which would
> upgrade seamlessy to the Groovy 3 implementation.
>
> Theme: Avoid discontinued JDK calls (i.e. reflection tricks)
>
> I actually thought it was worse, but Groovy only uses Unsafe for
> FastStringUtils in the groovy-json-direct subproject.
>
> We use “illegal” reflection tricks a lot and should migrate this to using
> method handles, as these have been promised to become really illegal in
> future JVM versions.
>
> Theme: Leaner Closures (native lambdas)
>
> There has been a lot of discussion around this, but I fear it’s been going
> in circles:
> Groovy’s closures are implemented as (generated) classes, whereas Java’s
> lambdas are implemented in methods. I’m thinking it should be possible to
> make Groovy’s closures leaner by using the same approach as Javas lambdas,
> but without sacrificing the unique features of closures in Groovy, AND still
> retaining their unique features, such as delegation.
>
> Finally, there was some consideration as to how things are done in Painless:
> http://groovy.329449.n5.nabble.com/new-MOP-under-Java9-module-system-findings-td5749016.html#a5749042
>
> This need not be tied to the syntax and semantics of Java lambdas, at all.
> See below for the discussion.
>
> Theme: Indy by default / New MOP
>
> See the discussion http://groovy.markmail.org/thread/yxeflplf5sr2wfqp
> This depends on whether or not we want to provide binary compatibility.
>
> Jochen did work on the new MOP a while ago, present in a branch in the repo,
> as presented here:
> https://www.slideshare.net/gr8conf/groovy-3-and-the-new-mop-in-examples
> There’s also a blog post here:
> http://blackdragsview.blogspot.dk/2015/03/thoughts-about-new-meta-class-system.html
> I’m thinking it makes a lot of sense, but I guess it needs to be broken down
> into bite size tasks.
> (See also link above around Painless for some MOP discussion)
>
> Theme: Improve “copy’n’paste-compatibility” with Java
>
> The original Java compatibility has been a nice gateway drug for Groovy
> beginners, and is worth considering in a number of cases:
>
> Try with resources - Partially done - needs doco changes
> Raw strings - Spiking stage (see GROOVY-8564)
> Array initialization - Partially done - needs doco changes
> Lambda syntax for closures - Done-ish? (native lambda is enabled only in the
> static mode for the time being - that is possibly final design). Or we
> ‘var’? (alias for `def` with some limitation, only used to declare variable)
> added in GROOVY-8498, but see GROOVY-8580 and GROOVY-8582.
> Method/constructor references - possible in Java syntax, but needs to more
> lean (AKA native method reference) and needs doco
> Default methods in interfaces - done using traits but we should consider
> native support and we need doco (can’t be called from Java, then, can they?)
> Static method in interfaces - TBD
> Improved switch syntax changes: might possibly be relevant before 3.0 is
> released (see GROOVY-8584)
>
> Be aware, this subject is really divisive: Some feel that Java compatibility
> should be a default, others that Groovy’s constructs are much more
> expressive and succinct.
> It has also been suggested Java features added for compatibility should be
> accompanied by a “unidiomatic Groovy”-warning.
>
> Next steps
>
> Decisions, that only the committers can really make:
>
> Did I forget anything?
> Are these themes relevant?
> Should some be deferred?
> So, should be have the discussions now, or defer tem to when/if somebody has
> implemented them?
>
>
> Thanks for reading.
>
> You can find the document at:
> https://docs.google.com/document/d/1gb0jLqQWOOkcqzlO25Af8dplQzq85qabNgpmC1vyBeg/edit?ts=5af9a2d4#heading=h.avsaw5h501ly
>
> Kind regards,
> Jesper
>
Re: Proposed Groovy 3.0 Scope
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Jesper,
The new MOP is really a big thing. Jochen is too busy to push the
progress, so I am not sure it will be included in Groovy 3.0.0. I wish some
company would sponsor him to complete the task...
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Proposed Groovy 3.0 Scope
Posted by "Daniel.Sun" <su...@apache.org>.
Enable indy by default and remove the legacy call site.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Proposed Groovy 3.0 Scope
Posted by mg <mg...@arscreat.com>.
Hi Jesper,
good overview document, thank you & would be great if you could help with Groovy 3.0 :-)
I agree that what is needed is progression towards decisions on some key questions...
Cheers,mg
PS: Under:"Lambda syntax for closures - Done-ish? (native lambda is enabled only in the static mode for the time being - that is possibly final design). Or we"there seems to be something missing....
-------- Ursprüngliche Nachricht --------Von: Jesper Steen Møller <je...@selskabet.org> Datum: 18.05.18 01:59 (GMT+01:00) An: dev@groovy.apache.org Betreff: Proposed Groovy 3.0 Scope
Groovy 3.0 Scope (suggestion)TL;DR: I want to help develop Groovy 3.0, but I'm not sure how: It appears that there's little consensus around priorities and scope. I'm suggesting a structure for discussing scope and setting priorities. HTH.IntroductionSeveral strands of Groovy development are going on at the moment, with different focus - and in the eyes of a would-be contributor, it’s difficult to find the best place to help. So, I’ve taken a step back and tried to get an overview.
This is my proposed laundry list of possible items for Groovy 3.0. It has been compiled by watching the dev-list, watching the Java development (8, 9, 10, 11…), reading blog posts and being a Groovy and Grails application developer since 2012, and listening to the input offered.
At the outset, it follows the discussion from the Apache Groovy Roadmap thread on the mailing list (from January 2017!)
I do know that several items are controversial, and I’m not trying to tip the scale in any direction. This is just a strawman, we’ll discuss it from here.Motivation for Groovy 3.0It’s 2018: Java is alive again, and Groovy is no longer “ahead but compatible”, rather the opposite. We need to address Java 9+ compatibility, leverage and augment features in Java 8+, and support newer deployment modes, such as lean microservice deployments - and be able to be deployed under JPMS.Compatibility GoalsGroovy 3.0 is a breaking change from Groovy 2.x, as it will require Java 8 or better. There should be no gratuitous incompatibilities, but some are required:A new MOP would likely break compatibility when calling Groovy 3-compiled code from a Groovy 2 runtime.A new MOP could be made compatible when calling Groovy 2-conpiled code from a Groovy 3 runtime.A new package structure would break compatibility. Adding the new classes as fronts for the old classes (and deprecating those) could help people writing for 2.x, like it is being done right now for CliBuilder.
I’ve broken the plan into a number of “themes”, in no particular order. The idea is to put these into epics in JIRA, and attach individual tasks to those.ThemesFit into Java Platform Module SystemAvoid discontinued JDK calls (i.e. reflection tricks)Leaner Closures (like native lambdas)Cleanup the MOPImprove “copy’n’paste-compatibility” with Java
These are expanded in the following sections.Breakdown of Development ThemesTheme: Fit into Java Platform Module SystemChop Groovy up into core and a set of extension modules - and change package names accordingly. Perhaps we should even divide into a runtime-only and compiler split, to allow for even smaller runtimes.
If we provide “bridge-APIs” in Groovy 2.x in the new package names, we could even allow for compatible code to be written i Groovy 2.5+ which would upgrade seamlessy to the Groovy 3 implementation.Theme: Avoid discontinued JDK calls (i.e. reflection tricks)I actually thought it was worse, but Groovy only uses Unsafe for FastStringUtils in the groovy-json-direct subproject.
We use “illegal” reflection tricks a lot and should migrate this to using method handles, as these have been promised to become really illegal in future JVM versions.Theme: Leaner Closures (native lambdas)There has been a lot of discussion around this, but I fear it’s been going in circles:Groovy’s closures are implemented as (generated) classes, whereas Java’s lambdas are implemented in methods. I’m thinking it should be possible to make Groovy’s closures leaner by using the same approach as Javas lambdas, but without sacrificing the unique features of closures in Groovy, AND still retaining their unique features, such as delegation.
Finally, there was some consideration as to how things are done in Painless: http://groovy.329449.n5.nabble.com/new-MOP-under-Java9-module-system-findings-td5749016.html#a5749042
This need not be tied to the syntax and semantics of Java lambdas, at all. See below for the discussion.Theme: Indy by default / New MOPSee the discussion http://groovy.markmail.org/thread/yxeflplf5sr2wfqpThis depends on whether or not we want to provide binary compatibility.
Jochen did work on the new MOP a while ago, present in a branch in the repo, as presented here: https://www.slideshare.net/gr8conf/groovy-3-and-the-new-mop-in-examplesThere’s also a blog post here: http://blackdragsview.blogspot.dk/2015/03/thoughts-about-new-meta-class-system.htmlI’m thinking it makes a lot of sense, but I guess it needs to be broken down into bite size tasks.(See also link above around Painless for some MOP discussion)Theme: Improve “copy’n’paste-compatibility” with JavaThe original Java compatibility has been a nice gateway drug for Groovy beginners, and is worth considering in a number of cases:Try with resources - Partially done - needs doco changesRaw strings - Spiking stage (see GROOVY-8564)Array initialization - Partially done - needs doco changesLambda syntax for closures - Done-ish? (native lambda is enabled only in the static mode for the time being - that is possibly final design). Or we ‘var’? (alias for `def` with some limitation, only used to declare variable) added in GROOVY-8498, but see GROOVY-8580 and GROOVY-8582.Method/constructor references - possible in Java syntax, but needs to more lean (AKA native method reference) and needs docoDefault methods in interfaces - done using traits but we should consider native support and we need doco (can’t be called from Java, then, can they?)Static method in interfaces - TBDImproved switch syntax changes: might possibly be relevant before 3.0 is released (see GROOVY-8584)Be aware, this subject is really divisive: Some feel that Java compatibility should be a default, others that Groovy’s constructs are much more expressive and succinct.It has also been suggested Java features added for compatibility should be accompanied by a “unidiomatic Groovy”-warning.Next stepsDecisions, that only the committers can really make:Did I forget anything?Are these themes relevant?Should some be deferred?So, should be have the discussions now, or defer tem to when/if somebody has implemented them?
Thanks for reading.
You can find the document at: https://docs.google.com/document/d/1gb0jLqQWOOkcqzlO25Af8dplQzq85qabNgpmC1vyBeg/edit?ts=5af9a2d4#heading=h.avsaw5h501ly
Kind regards,Jesper