Re: Proposed Groovy 3.0 Scope

[Daniel.Sun]

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

[Jesper Steen Møller]

> On 22 May 2018, at 10.35, Paul King  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

[Daniel.Sun]

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

[Paul King]

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 
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 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 pos

Re: Proposed Groovy 3.0 Scope

[Roman Shaposhnik]

>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
 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)
>

Re: Proposed Groovy 3.0 Scope

[Daniel.Sun]

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

[mg]

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 
 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-

Proposed Groovy 3.0 Scope

[Jesper Steen Møller]

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