You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Cédric Champeau <cc...@apache.org> on 2017/01/31 08:37:38 UTC
[VOTE] Apache Groovy Roadmap
Hi guys,
There are multiple conversations going on for weeks, and I think they are
going nowhere. We could discuss for months what's the best plan for Groovy,
without releasing anything. Here are the challenges that are waiting for us:
1. release a version of Groovy that integrates Groovy macros
2. upgrade the minimal runtime required for Groovy to 1.7, which is
required to smoothly transition to higher requirements (and also, make our
devs lives easier)
3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
drop the old call site caching and use indy Groovy everywhere
4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
5. compatibility with Jigsaw, aka "Groovy as a module"
I would like to propose the following plan:
- Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
for this for too long
- Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
- Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
changes (we have no choice here)
This plan is, I think, a good compromise for all the requirements we have:
backwards compatibility, and making progress and not having too many
branches. An alternative would be to keep Parrot on Java 8, but as some of
us have said, this is incompatible with a soonish release. The drawback is
that Parrot has the risk of being a breaking change (it is, typically if
people implicitly depend on the old parser, which would be bad), so there's
a risk of not following semantic versioning.
- [ ] YES, I approve the roadmap above
- [ ] NO, I do not approve the roadmap abobe beause...
- [ ] I don't mind, or this goes beyond what I can think of
This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
Re: [VOTE] Apache Groovy Roadmap
Posted by Jochen Theodorou <bl...@gmx.org>.
On 31.01.2017 11:11, Remi Forax wrote:
[...]
> Jigsaw is more or less forward compatible, i.e. you can release jars
> that will use Java 8 to compile (or Java 9 in release mode 8) and also
> make them jigsaw compatible in term of dependencies.
> Obviously the module graph will be read only on Java 9 but the classpath
> will work on Java 8 (and on Java 9).
Groovy as anonymous module should work right now... at least if you open
a lot of packages. Groovy as a module is a totally different story,
because we will basically need the same rights that are right now
granted to a an anonymous module as normal module, including all the
dynamic module handling via layers. And adoption of Groovy in a jigsaw
module world depends on Groovy being able to run as module imho.
The issues we will have under Java9 are mostly these:
(1) setAccessible based logic no longer working, which breaks programs
that rely on non-public data members from Java classes
(2) URLClassLoader assumption no longer valid breaks all programs using
@Grab and requiring the systemloader
(3) joint compilation needs to be able to compile a module
I doubt there is going to be a solution for 2, changing 1 will be a huge
amount of work, since it is not simply done by moving over to
invokedynamic, the initialization sequence of meta classes will be
influenced as well. The alternative is dozens of add-opens on the
command line right now.
And even the solution to that seems to be far fetched... because it
looks like I will need an agent manipulating every module that comes
into contact with Groovy to give Groovy extended rights right now.
Number 3 is not even investigated. But of course the biggest piece is
Groovy as a module itself.
So it is not so much us doing changes that will not work under earlier
JVMs, it is that there will be a major change in how Groovy behaves as a
library, because of the restrictions imposed by the module system. And
that enabling only the slightest bit beyond what we have now, means
bigger changes in how the MOP works may come. And that is why it is a
"blow up everything" version
bye Jochen
Re: [VOTE] Apache Groovy Roadmap
Posted by Remi Forax <fo...@univ-mlv.fr>.
> De: "Alessio Stalla" <al...@gmail.com>
> À: dev@groovy.apache.org
> Envoyé: Mardi 31 Janvier 2017 11:04:00
> Objet: Re: [VOTE] Apache Groovy Roadmap
> Sorry if outsiders are not meant to chime in :)
> Why not
> - 2.5 as Cédric proposed (so Java 7 + macros)
> - 3.0 with Java 8 and Parrot
> - 4.0 with Java 9 and Jigsaw?
Jigsaw is more or less forward compatible, i.e. you can release jars that will use Java 8 to compile (or Java 9 in release mode 8) and also make them jigsaw compatible in term of dependencies.
Obviously the module graph will be read only on Java 9 but the classpath will work on Java 8 (and on Java 9).
> This way Groovy versions and Java versions are nicely aligned. To let people try
> Parrot early, there could be a 3.0 early access release that only replaces the
> antlr2-based parser with Parrot and bumps the required Java version to 8.
Rémi
> On 31 January 2017 at 10:55, Cédric Champeau < cedric.champeau@gmail.com >
> wrote:
>> 2017-01-31 10:46 GMT+01:00 Jochen Theodorou < blackdrag@gmx.org > :
>>> On 31.01.2017 09:37, Cédric Champeau wrote:
>>>> Hi guys,
>>>> There are multiple conversations going on for weeks, and I think they
>>>> are going nowhere. We could discuss for months what's the best plan for
>>>> Groovy, without releasing anything. Here are the challenges that are
>>>> waiting for us:
>>>> 1. release a version of Groovy that integrates Groovy macros
>>>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
>>>> required to smoothly transition to higher requirements (and also, make
>>>> our devs lives easier)
>>>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
>>>> to drop the old call site caching and use indy Groovy everywhere
>>>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>>>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>>> I would like to propose the following plan:
>>>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
>>>> waiting for this for too long
>>>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>>>> - Groovy 3.0: integrate 3 and 5. The only version with necessary
>>>> breaking changes (we have no choice here)
>>> If you insist on a removal of antlr2, then this will be a breaking change, since
>>> we leak antlr2 classes in several places. 2.6 is then only an option if antlr2
>>> stays. And considering your earlier statements that there should be only one
>>> parser, that means 2.6 has to be 3.0.
>>> And considering that there is now a Java7 version of Parrot and that there will
>>> be at least two major versions before we are on JDK8... why not just go with
>>> 3.0 right away?
>> Because macro groovy doesn't have to be bound with breaking changes.
>>> So my -1 based on your argumentation from my side. An alternative plan:
>>> no 2.5
>>> - 3.0 with macro methods and Java7 and parrot
>>> - 4.0 java8 and jigsaw
>>> bye Jochen
Re: [VOTE] Apache Groovy Roadmap
Posted by Alessio Stalla <al...@gmail.com>.
Sorry if outsiders are not meant to chime in :)
Why not
- 2.5 as Cédric proposed (so Java 7 + macros)
- 3.0 with Java 8 and Parrot
- 4.0 with Java 9 and Jigsaw?
This way Groovy versions and Java versions are nicely aligned. To let
people try Parrot early, there could be a 3.0 early access release that
only replaces the antlr2-based parser with Parrot and bumps the required
Java version to 8.
On 31 January 2017 at 10:55, Cédric Champeau <ce...@gmail.com>
wrote:
>
>
> 2017-01-31 10:46 GMT+01:00 Jochen Theodorou <bl...@gmx.org>:
>
>>
>>
>> On 31.01.2017 09:37, Cédric Champeau wrote:
>>
>>> Hi guys,
>>>
>>> There are multiple conversations going on for weeks, and I think they
>>> are going nowhere. We could discuss for months what's the best plan for
>>> Groovy, without releasing anything. Here are the challenges that are
>>> waiting for us:
>>>
>>> 1. release a version of Groovy that integrates Groovy macros
>>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
>>> required to smoothly transition to higher requirements (and also, make
>>> our devs lives easier)
>>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
>>> to drop the old call site caching and use indy Groovy everywhere
>>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>>
>> >
>>
>>> I would like to propose the following plan:
>>>
>>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
>>> waiting for this for too long
>>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>>> - Groovy 3.0: integrate 3 and 5. The only version with necessary
>>> breaking changes (we have no choice here)
>>>
>>
>> If you insist on a removal of antlr2, then this will be a breaking
>> change, since we leak antlr2 classes in several places. 2.6 is then only an
>> option if antlr2 stays. And considering your earlier statements that there
>> should be only one parser, that means 2.6 has to be 3.0.
>>
>> And considering that there is now a Java7 version of Parrot and that
>> there will be at least two major versions before we are on JDK8... why not
>> just go with 3.0 right away?
>>
>
> Because macro groovy doesn't have to be bound with breaking changes.
>
>
>>
>> So my -1 based on your argumentation from my side. An alternative plan:
>>
>> no 2.5
>> - 3.0 with macro methods and Java7 and parrot
>> - 4.0 java8 and jigsaw
>>
>> bye Jochen
>>
>
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Cédric Champeau <ce...@gmail.com>.
For the beta, it's not super important. For the release I mentioned I
wanted an opt-in mechanism in the past, so it shouldn't be a breaking
change.
2017-01-31 16:33 GMT+01:00 Daniel Sun <re...@hotmail.com>:
> Hi Cédric,
>
> > Because macro groovy doesn't have to be bound with breaking changes.
> If program has already used "macro" method name, what will happen?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738271.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Daniel Sun <re...@hotmail.com>.
Hi Cédric,
> Because macro groovy doesn't have to be bound with breaking changes.
If program has already used "macro" method name, what will happen?
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738271.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: [VOTE] Apache Groovy Roadmap
Posted by Cédric Champeau <ce...@gmail.com>.
2017-01-31 10:46 GMT+01:00 Jochen Theodorou <bl...@gmx.org>:
>
>
> On 31.01.2017 09:37, Cédric Champeau wrote:
>
>> Hi guys,
>>
>> There are multiple conversations going on for weeks, and I think they
>> are going nowhere. We could discuss for months what's the best plan for
>> Groovy, without releasing anything. Here are the challenges that are
>> waiting for us:
>>
>> 1. release a version of Groovy that integrates Groovy macros
>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
>> required to smoothly transition to higher requirements (and also, make
>> our devs lives easier)
>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
>> to drop the old call site caching and use indy Groovy everywhere
>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>
> >
>
>> I would like to propose the following plan:
>>
>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
>> waiting for this for too long
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary
>> breaking changes (we have no choice here)
>>
>
> If you insist on a removal of antlr2, then this will be a breaking change,
> since we leak antlr2 classes in several places. 2.6 is then only an option
> if antlr2 stays. And considering your earlier statements that there should
> be only one parser, that means 2.6 has to be 3.0.
>
> And considering that there is now a Java7 version of Parrot and that there
> will be at least two major versions before we are on JDK8... why not just
> go with 3.0 right away?
>
Because macro groovy doesn't have to be bound with breaking changes.
>
> So my -1 based on your argumentation from my side. An alternative plan:
>
> no 2.5
> - 3.0 with macro methods and Java7 and parrot
> - 4.0 java8 and jigsaw
>
> bye Jochen
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Graeme Rocher <gr...@gmail.com>.
YES from me.
IMO we should not be waiting until 3.x for Parrot however, I am also
ok with the proposal to change the roadmap so that Groovy 3.x is the
Parrot release and Groovy 4.x the breaking Jigsaw/Java 8/9 release.
The sooner we get folks testing Parrot in the real world the better
and if we wait more it will be a very long time before we see Parrot
or any of the new features used in a project.
Cheers
On Tue, Jan 31, 2017 at 1:46 PM, Sven Reimers <sv...@gmail.com> wrote:
> I would be volunteering for checking if this is a problem in NetBeans Groovy
> Support. What are the patterns I should look for?
>
> Already any branch I could build and try as an experiment?
>
> Thanks
>
> Sven
>
> Am 31.01.2017 12:46 schrieb "Jochen Theodorou" <bl...@gmx.org>:
>>
>> [..]
>>>
>>> Were exactly was this leak? The antlr2 classes are jarjar'ed, right -
>>> they were hardly API. Or am I missing something?
>>> As for usage: A quick search on GitHub for the string
>>> 'groovyjarjarantlr' revealed 12 commits, most of them in Adempiere and
>>> 'groovy-class-parser', in pretty old code.
>>
>>
>> I am thinking for example of the groovy-eclipse plugin. Also we do not
>> catch all exceptions thrown by antlr afaik.
>>
>> But maybe I overestimate the problem
>>
>> bye Jochen
--
Graeme Rocher
Re: [VOTE] Apache Groovy Roadmap
Posted by Sven Reimers <sv...@gmail.com>.
I would be volunteering for checking if this is a problem in NetBeans
Groovy Support. What are the patterns I should look for?
Already any branch I could build and try as an experiment?
Thanks
Sven
Am 31.01.2017 12:46 schrieb "Jochen Theodorou" <bl...@gmx.org>:
> [..]
>
>> Were exactly was this leak? The antlr2 classes are jarjar'ed, right -
>> they were hardly API. Or am I missing something?
>> As for usage: A quick search on GitHub for the string
>> 'groovyjarjarantlr' revealed 12 commits, most of them in Adempiere and
>> 'groovy-class-parser', in pretty old code.
>>
>
> I am thinking for example of the groovy-eclipse plugin. Also we do not
> catch all exceptions thrown by antlr afaik.
>
> But maybe I overestimate the problem
>
> bye Jochen
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Jochen Theodorou <bl...@gmx.org>.
[..]
> Were exactly was this leak? The antlr2 classes are jarjar'ed, right -
> they were hardly API. Or am I missing something?
> As for usage: A quick search on GitHub for the string
> 'groovyjarjarantlr' revealed 12 commits, most of them in Adempiere and
> 'groovy-class-parser', in pretty old code.
I am thinking for example of the groovy-eclipse plugin. Also we do not
catch all exceptions thrown by antlr afaik.
But maybe I overestimate the problem
bye Jochen
Re: [VOTE] Apache Groovy Roadmap
Posted by Jesper Steen Møller <je...@selskabet.org>.
On 31 Jan 2017, at 10.46, Jochen Theodorou <bl...@gmx.org> wrote:
>
>
> On 31.01.2017 09:37, Cédric Champeau wrote:
>>
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary
>> breaking changes (we have no choice here)
>
> If you insist on a removal of antlr2, then this will be a breaking change, since we leak antlr2 classes in several places. 2.6 is then only an option if antlr2 stays. And considering your earlier statements that there should be only one parser, that means 2.6 has to be 3.0.
>
Were exactly was this leak? The antlr2 classes are jarjar'ed, right - they were hardly API. Or am I missing something?
As for usage: A quick search on GitHub for the string 'groovyjarjarantlr' revealed 12 commits, most of them in Adempiere and 'groovy-class-parser', in pretty old code.
YES to Cedrics proposal (if I'm eligible to vote, that is)
-Jesper
Re: [VOTE] Apache Groovy Roadmap
Posted by Jochen Theodorou <bl...@gmx.org>.
On 31.01.2017 09:37, C�dric Champeau wrote:
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they
> are going nowhere. We could discuss for months what's the best plan for
> Groovy, without releasing anything. Here are the challenges that are
> waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make
> our devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
> to drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
> waiting for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary
> breaking changes (we have no choice here)
If you insist on a removal of antlr2, then this will be a breaking
change, since we leak antlr2 classes in several places. 2.6 is then only
an option if antlr2 stays. And considering your earlier statements that
there should be only one parser, that means 2.6 has to be 3.0.
And considering that there is now a Java7 version of Parrot and that
there will be at least two major versions before we are on JDK8... why
not just go with 3.0 right away?
So my -1 based on your argumentation from my side. An alternative plan:
no 2.5
- 3.0 with macro methods and Java7 and parrot
- 4.0 java8 and jigsaw
bye Jochen
Re: [VOTE] Apache Groovy Roadmap
Posted by Jochen Theodorou <bl...@gmx.org>.
I would like to have a clarification on 2 things before we really make a
new version:
* is changing to java7 as default a breaking change and requires a new
major version? (that implies 3.0 soon and 4.0 for java8 not long after)
* is it acceptable to have optional java8 only components (for example
the parser) as part of a Groovy version with java7 or java6 as minimum
requirement?
* do we want to have a version in which the parrot parser is the
optional default?
My answers would be: yes, yes and yes.
bye Jochen
On 02.02.2017 14:03, Graeme Rocher wrote:
> I'm in agreement that we should not commit to behaviour that we
> believe to be wrong and later break it (i.e. lambda's)
>
> So if we agree on a version that should be "the Parrot release"
> whether that is 2.6 or 3.0 we have to scope into that work resolving
> the semantics discussion.
>
> Cheers
>
> On Thu, Feb 2, 2017 at 12:47 PM, Jesper Steen M�ller
> <je...@selskabet.org> wrote:
>> Hi list
>>
>> On 2 Feb 2017, at 11.58, Paul King <pa...@asert.com.au> wrote:
>>
>> This thread has kind of gone into debate mode but I guess for the
>> record I would be -1 on any releases having parrot that weren't marked
>> as "experimental" or "incubating" until we thrash out future plans for
>> dealing with Java 8 features (default methods on interfaces/"real"
>> lambda expressions).
>>
>>
>> For this discussion, please note the difference between the parser
>> implementation and the new language features. Yes, at the moment, Parrot has
>> both.
>>
>> Upping the parser implementation only breaks compatibility in these cases:
>> 1) For clients who depend on the jarjar'ed antlr2 binaries or leaked
>> exceptions. This is IMHO bad form, but is likely required in projects the
>> groovy-eclipse plugin, as Jochen pointed out. These will need to update
>> anyway.
>> 2) A few grammar bugs in the old parser have been fixed, but AFAIK only for
>> confirmed bugs. Fixing a known bug is not a breaking change.
>> Obviously, the new parser can contain bugs, too, so testing should not be
>> taken lightly.
>>
>> Changing the language can be a breaking change. For now, Parrot adds the
>> syntax of Java 8 lambdas and method and constructor references to Groovy,
>> but with Groovy semantics,
>> Adding those can't be considered breaking as long as they only add new to
>> the language which weren't syntactically legal before?
>> But: As you rightly point out, the semantics of these haven't been explored
>> in depth, and there are pitfalls in addition to the one you mention: For
>> example: Adding lambdas as synonyms for closures (as they are now in the
>> parrot-branch), and later changing them to be Java 8 source compatible, e.g.
>> terms of how they resolve 'this', would be a breaking change.
>>
>> Where I'm getting at:
>> 1. Introducing Parrot needn't break anything.
>> 2. The roadmap suggested by C�dric doesn't stop us from having the Java 8
>> semantics-discussions right now, in time for the proposed 2.6.
>> 3. Major numbers should only be used if we mean to break stuff. Parrot
>> shouldn't.
>>
>> Kind regards
>> Jesper
>>
>>
>> On Tue, Jan 31, 2017 at 6:37 PM, C�dric Champeau <cc...@apache.org>
>> wrote:
>>
>> Hi guys,
>>
>> There are multiple conversations going on for weeks, and I think they are
>> going nowhere. We could discuss for months what's the best plan for Groovy,
>> without releasing anything. Here are the challenges that are waiting for us:
>>
>> 1. release a version of Groovy that integrates Groovy macros
>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required
>> to smoothly transition to higher requirements (and also, make our devs lives
>> easier)
>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
>> drop the old call site caching and use indy Groovy everywhere
>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>
>> I would like to propose the following plan:
>>
>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
>> for this for too long
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
>> changes (we have no choice here)
>>
>> This plan is, I think, a good compromise for all the requirements we have:
>> backwards compatibility, and making progress and not having too many
>> branches. An alternative would be to keep Parrot on Java 8, but as some of
>> us have said, this is incompatible with a soonish release. The drawback is
>> that Parrot has the risk of being a breaking change (it is, typically if
>> people implicitly depend on the old parser, which would be bad), so there's
>> a risk of not following semantic versioning.
>>
>> - [ ] YES, I approve the roadmap above
>> - [ ] NO, I do not approve the roadmap abobe beause...
>> - [ ] I don't mind, or this goes beyond what I can think of
>>
>> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>>
>>
>
>
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Graeme Rocher <gr...@gmail.com>.
I'm in agreement that we should not commit to behaviour that we
believe to be wrong and later break it (i.e. lambda's)
So if we agree on a version that should be "the Parrot release"
whether that is 2.6 or 3.0 we have to scope into that work resolving
the semantics discussion.
Cheers
On Thu, Feb 2, 2017 at 12:47 PM, Jesper Steen Møller
<je...@selskabet.org> wrote:
> Hi list
>
> On 2 Feb 2017, at 11.58, Paul King <pa...@asert.com.au> wrote:
>
> This thread has kind of gone into debate mode but I guess for the
> record I would be -1 on any releases having parrot that weren't marked
> as "experimental" or "incubating" until we thrash out future plans for
> dealing with Java 8 features (default methods on interfaces/"real"
> lambda expressions).
>
>
> For this discussion, please note the difference between the parser
> implementation and the new language features. Yes, at the moment, Parrot has
> both.
>
> Upping the parser implementation only breaks compatibility in these cases:
> 1) For clients who depend on the jarjar'ed antlr2 binaries or leaked
> exceptions. This is IMHO bad form, but is likely required in projects the
> groovy-eclipse plugin, as Jochen pointed out. These will need to update
> anyway.
> 2) A few grammar bugs in the old parser have been fixed, but AFAIK only for
> confirmed bugs. Fixing a known bug is not a breaking change.
> Obviously, the new parser can contain bugs, too, so testing should not be
> taken lightly.
>
> Changing the language can be a breaking change. For now, Parrot adds the
> syntax of Java 8 lambdas and method and constructor references to Groovy,
> but with Groovy semantics,
> Adding those can't be considered breaking as long as they only add new to
> the language which weren't syntactically legal before?
> But: As you rightly point out, the semantics of these haven't been explored
> in depth, and there are pitfalls in addition to the one you mention: For
> example: Adding lambdas as synonyms for closures (as they are now in the
> parrot-branch), and later changing them to be Java 8 source compatible, e.g.
> terms of how they resolve 'this', would be a breaking change.
>
> Where I'm getting at:
> 1. Introducing Parrot needn't break anything.
> 2. The roadmap suggested by Cédric doesn't stop us from having the Java 8
> semantics-discussions right now, in time for the proposed 2.6.
> 3. Major numbers should only be used if we mean to break stuff. Parrot
> shouldn't.
>
> Kind regards
> Jesper
>
>
> On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau <cc...@apache.org>
> wrote:
>
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required
> to smoothly transition to higher requirements (and also, make our devs lives
> easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
>
--
Graeme Rocher
Re: [VOTE] Apache Groovy Roadmap
Posted by Keith Suderman <su...@anc.org>.
> On Feb 2, 2017, at 6:47 AM, Jesper Steen Møller <je...@selskabet.org> wrote:
>
> 3. Major numbers should only be used if we mean to break stuff. Parrot shouldn't.
> On Feb 2, 2017, at 10:03 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>
> I would like to have a clarification on 2 things before we really make a new version:
>
> * is changing to java7 as default a breaking change and requires a new major version? (that implies 3.0 soon and 4.0 for java8 not long after)
The Semantic Version spec states that the major version MUST be incremented if the release contains breaking changes, but the inverse is not true, that is, the major version can be incremented even if the release does not include breaking changes. I am of the opinion that the inclusion of Parrot + requiring Java 7 are big enough developments to warrant an increase in the major version even if nothing breaks.
Cheers,
Keith
>
> Kind regards
> Jesper
>
>>
>> On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau <cchampeau@apache.org <ma...@apache.org>> wrote:
>>> Hi guys,
>>>
>>> There are multiple conversations going on for weeks, and I think they are
>>> going nowhere. We could discuss for months what's the best plan for Groovy,
>>> without releasing anything. Here are the challenges that are waiting for us:
>>>
>>> 1. release a version of Groovy that integrates Groovy macros
>>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required
>>> to smoothly transition to higher requirements (and also, make our devs lives
>>> easier)
>>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
>>> drop the old call site caching and use indy Groovy everywhere
>>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>>
>>> I would like to propose the following plan:
>>>
>>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
>>> for this for too long
>>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>>> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
>>> changes (we have no choice here)
>>>
>>> This plan is, I think, a good compromise for all the requirements we have:
>>> backwards compatibility, and making progress and not having too many
>>> branches. An alternative would be to keep Parrot on Java 8, but as some of
>>> us have said, this is incompatible with a soonish release. The drawback is
>>> that Parrot has the risk of being a breaking change (it is, typically if
>>> people implicitly depend on the old parser, which would be bad), so there's
>>> a risk of not following semantic versioning.
>>>
>>> - [ ] YES, I approve the roadmap above
>>> - [ ] NO, I do not approve the roadmap abobe beause...
>>> - [ ] I don't mind, or this goes beyond what I can think of
>>>
>>> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>>>
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Jesper Steen Møller <je...@selskabet.org>.
Hi list
> On 2 Feb 2017, at 11.58, Paul King <pa...@asert.com.au> wrote:
>
> This thread has kind of gone into debate mode but I guess for the
> record I would be -1 on any releases having parrot that weren't marked
> as "experimental" or "incubating" until we thrash out future plans for
> dealing with Java 8 features (default methods on interfaces/"real"
> lambda expressions).
For this discussion, please note the difference between the parser implementation and the new language features. Yes, at the moment, Parrot has both.
Upping the parser implementation only breaks compatibility in these cases:
1) For clients who depend on the jarjar'ed antlr2 binaries or leaked exceptions. This is IMHO bad form, but is likely required in projects the groovy-eclipse plugin, as Jochen pointed out. These will need to update anyway.
2) A few grammar bugs in the old parser have been fixed, but AFAIK only for confirmed bugs. Fixing a known bug is not a breaking change.
Obviously, the new parser can contain bugs, too, so testing should not be taken lightly.
Changing the language can be a breaking change. For now, Parrot adds the syntax of Java 8 lambdas and method and constructor references to Groovy, but with Groovy semantics,
Adding those can't be considered breaking as long as they only add new to the language which weren't syntactically legal before?
But: As you rightly point out, the semantics of these haven't been explored in depth, and there are pitfalls in addition to the one you mention: For example: Adding lambdas as synonyms for closures (as they are now in the parrot-branch), and later changing them to be Java 8 source compatible, e.g. terms of how they resolve 'this', would be a breaking change.
Where I'm getting at:
1. Introducing Parrot needn't break anything.
2. The roadmap suggested by Cédric doesn't stop us from having the Java 8 semantics-discussions right now, in time for the proposed 2.6.
3. Major numbers should only be used if we mean to break stuff. Parrot shouldn't.
Kind regards
Jesper
>
> On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau <cc...@apache.org> wrote:
>> Hi guys,
>>
>> There are multiple conversations going on for weeks, and I think they are
>> going nowhere. We could discuss for months what's the best plan for Groovy,
>> without releasing anything. Here are the challenges that are waiting for us:
>>
>> 1. release a version of Groovy that integrates Groovy macros
>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required
>> to smoothly transition to higher requirements (and also, make our devs lives
>> easier)
>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
>> drop the old call site caching and use indy Groovy everywhere
>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>
>> I would like to propose the following plan:
>>
>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
>> for this for too long
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
>> changes (we have no choice here)
>>
>> This plan is, I think, a good compromise for all the requirements we have:
>> backwards compatibility, and making progress and not having too many
>> branches. An alternative would be to keep Parrot on Java 8, but as some of
>> us have said, this is incompatible with a soonish release. The drawback is
>> that Parrot has the risk of being a breaking change (it is, typically if
>> people implicitly depend on the old parser, which would be bad), so there's
>> a risk of not following semantic versioning.
>>
>> - [ ] YES, I approve the roadmap above
>> - [ ] NO, I do not approve the roadmap abobe beause...
>> - [ ] I don't mind, or this goes beyond what I can think of
>>
>> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>>
Re: [VOTE] Apache Groovy Roadmap
Posted by Daniel Sun <re...@hotmail.com>.
As to the new features of Java 8, Parrot provides the same syntax but the backend is based on the existing groovy runtime. The approach can make some differences between Groovy and Java 8. Whether these differences are allowed or not depends on GLS. Like the inner class behaves a bit differently with Java's(http://groovy-lang.org/differences.html#_inner_classes), lambda expression of Groovy can also have its own features and can be a bit different with lambda expression of Java.
If most of us do not like the Groovy version of lambda expression(though it's much more powerful), IMO the best way to make Groovy behave same with Java is to study how to generate bytecode for LambdaExpression on the parrot branch(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java).
Cheers,
Daniel.Sun
在 2017年2月2日 下午6:59，"paulk_asert [via Groovy]" <ml...@n5.nabble.com>写道：<br type="attri
This thread has kind of gone into debate mode but I guess for the
record I would be -1 on any releases having parrot that weren't marked
as "experimental" or "incubating" until we thrash out future plans for
dealing with Java 8 features (default methods on interfaces/"real"
lambda expressions). I don't think we need to wait until those plans
are finalised but we should know whether we'd support them down the
track and plan accordingly. And I'd be +1 on getting out such
"experimental"/"incubating" releases soon.
I am +1 on getting 2.4.9 and a 2.5.0-beta out soon. I am hoping to
have my review of macros finished by the end of next week but it would
be good for at least one other person to review.
I would also not be against upping the semantic versioning ante and
renaming 2.5 to 3.0. If we did this renaming, I'd be keen to have an
easy way to use parrot (an experimental/incubating version of the
backport jar?). If after more experimentation we find no significant
breaking changes, it could be merged into a 3.1, otherwise we should
release a 4.0 with that. The jigsaw breaking changes would become 5.0
then I guess.
Cheers, Paul.
On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau <[hidden email]</user/SendEmail.jtp?type=node&node=5738403&i=0>> wrote:
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required
> to smoothly transition to higher requirements (and also, make our devs lives
> easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738403.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738406.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: [VOTE] Apache Groovy Roadmap
Posted by Paul King <pa...@asert.com.au>.
This thread has kind of gone into debate mode but I guess for the
record I would be -1 on any releases having parrot that weren't marked
as "experimental" or "incubating" until we thrash out future plans for
dealing with Java 8 features (default methods on interfaces/"real"
lambda expressions). I don't think we need to wait until those plans
are finalised but we should know whether we'd support them down the
track and plan accordingly. And I'd be +1 on getting out such
"experimental"/"incubating" releases soon.
I am +1 on getting 2.4.9 and a 2.5.0-beta out soon. I am hoping to
have my review of macros finished by the end of next week but it would
be good for at least one other person to review.
I would also not be against upping the semantic versioning ante and
renaming 2.5 to 3.0. If we did this renaming, I'd be keen to have an
easy way to use parrot (an experimental/incubating version of the
backport jar?). If after more experimentation we find no significant
breaking changes, it could be merged into a 3.1, otherwise we should
release a 4.0 with that. The jigsaw breaking changes would become 5.0
then I guess.
Cheers, Paul.
On Tue, Jan 31, 2017 at 6:37 PM, Cédric Champeau <cc...@apache.org> wrote:
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required
> to smoothly transition to higher requirements (and also, make our devs lives
> easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
答复: Lambda vs. Closure
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jochen,
Gotcha 😊
BTW, Generating the real lambda needs type information which is only available in the static compilation mode…so it’s impossible to have universal version of lambda if we want to implement the real lambda.
Cheers,
Daniel.Sun
发件人: Jochen Theodorou [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月8日 0:53
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: Lambda vs. Closure
On 07.02.2017 16:44, Jesper Steen Møller wrote:
[...]
> Generating faster/tighter code for lambdas (or even closures) can be
> implemented as a separate task, the two aren't really interconnected,
> since the Groovy closure is so versatile to begin with.
The problem is that Closure has delegates, owners and several other
things, that make no sense for lambdas in the sense of Java. In other
words: Closure does too much and is too heavy weight
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738489.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738490.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda vs. Closure
Posted by Jochen Theodorou <bl...@gmx.org>.
On 07.02.2017 16:44, Jesper Steen M�ller wrote:
[...]
> Generating faster/tighter code for lambdas (or even closures) can be
> implemented as a separate task, the two aren't really interconnected,
> since the Groovy closure is so versatile to begin with.
The problem is that Closure has delegates, owners and several other
things, that make no sense for lambdas in the sense of Java. In other
words: Closure does too much and is too heavy weight
bye Jochen
答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
I’ve opened a new vote for the implementation of lambda expression, you can find it in the dev-list 😉
Cheers,
Daniel.Sun
发件人: 孙 岚<ma...@hotmail.com>
发送时间: 2017年2月7日 23:49
收件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
主题: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Hi Jesper,
Gotcha 😊
For me, I don’t like two versions of lambda expression… it will confuse developers.
Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 23:44
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
On 7 Feb 2017, at 16.27, Daniel Sun <[hidden email]</user/SendEmail.jtp?type=node&node=5738482&i=0>> wrote:
To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
A real lambda expression is implemented in Java as an invokedynamic call which makes use of a bootstrap method calling into a class called the LambdaMetafactory (https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html) , and puts the body of the lambda expression into a hidden method on the class. The LambdaMetafactory sets up the magic class which holds any escaped variables and implements the functional interface. To work, it requires EXACT type information, so it's only possible to do this in static compilation.
1. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
I'm not sure why we need a separate discussion.
We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Generating faster/tighter code for lambdas (or even closures) can be implemented as a separate task, the two aren't really interconnected, since the Groovy closure is so versatile to begin with.
-Jesper
发件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 23:10
收件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
On 7 Feb 2017, at 16.00, Daniel Sun <<a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738478&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
Cheers,
Daniel.Sun
发件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=0" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 22:23
收件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=1" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
View this message in context: 答复: [VOTE] Apache Groovy Roadmap<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://nabble.com/>.
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
View this message in context: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://Nabble.com>.
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738482.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
255BE998123446CE821944FE06B16C99.png (190 bytes) <http://groovy.329449.n5.nabble.com/attachment/5738487/0/255BE998123446CE821944FE06B16C99.png>
F479E271DD254A61A9EF12764CF76C5A.png (206 bytes) <http://groovy.329449.n5.nabble.com/attachment/5738487/1/F479E271DD254A61A9EF12764CF76C5A.png>
E7B2A2AE4D2C495D89D99052E580861B.png (202 bytes) <http://groovy.329449.n5.nabble.com/attachment/5738487/2/E7B2A2AE4D2C495D89D99052E580861B.png>
D4297BE0AA2D4CA59AA5F5D147DBB27A.png (210 bytes) <http://groovy.329449.n5.nabble.com/attachment/5738487/3/D4297BE0AA2D4CA59AA5F5D147DBB27A.png>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738487.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: 答复: Lambda vs. Closure
Posted by Jochen Theodorou <bl...@gmx.org>.
On 07.02.2017 17:39, Daniel Sun wrote:
[...]
>
> * We have a basic choice: 1) Use Java-lambda semantics or 2)
> Groovy-closure semantics. As a variation on 2, we can add some help
> for people pasting Java code into a Groovy program.
>
>
> Agreed.
hmm... let me add some thoughts to this...
I see a lambda as a kind of lightweight proxy, that provides an
implementation for a series of functional interfaces. In that matter
they are like "closure as SomeFunctionalInterface", only that our
solution is not lightweight.
Since we know the internals we can ignore the proxy facade and directly
use the method that realizes the proxy. All that is then required is to
transform call arguments to the types the implementing method needs.
It would be very possible to use the LambdaMetaFactory for for example
"closure as SomeFunctionalInterface".
At the same time we can provide our own LambdaMetaFactory (ignoring
Java9 problems). The "problem" is the identity of the implementing
method and what signature you use for it. In dynamic Groovy you can go
with object for most parts and have no trouble.
What we are really missing is the ability to decide at compile time
between two overloaded methods each taking functional interfaces. Only
this requires extended static analysis. If we delay that part to
runtime, like we do today for SAM Closures, then we do not need this as
long as the interfaces differ on a level recognizable after type erasure.
if we have for example one method taking List<A> and another taking
List<B> as parameter type for the method of the functional interface,
then we really really need a static analysis.
In the end that boils for me down to:
* dynamic Groovy can most probably not use LambdaMetaFactory and could
probably use the already existing ifrastructure the invokedynamic port
provides.
* static Groovy can use LambdaMetaFactory but needs to be improved on
the compiler level
bye Jochen
答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
* I'm not sure why we need a separate discussion.
If most of us want the current lambda expression(based on closure), we need not thrash out how to implement Java-lambda semantics 😉
* We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Agreed.
P.S. I have not seen your above words…
Cheers,
Daniel.Sun
发件人: 孙 岚<ma...@hotmail.com>
发送时间: 2017年2月7日 23:49
收件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
主题: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Hi Jesper,
Gotcha 😊
For me, I don’t like two versions of lambda expression… it will confuse developers.
Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 23:44
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
On 7 Feb 2017, at 16.27, Daniel Sun <[hidden email]</user/SendEmail.jtp?type=node&node=5738482&i=0>> wrote:
To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
A real lambda expression is implemented in Java as an invokedynamic call which makes use of a bootstrap method calling into a class called the LambdaMetafactory (https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html) , and puts the body of the lambda expression into a hidden method on the class. The LambdaMetafactory sets up the magic class which holds any escaped variables and implements the functional interface. To work, it requires EXACT type information, so it's only possible to do this in static compilation.
* For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
I'm not sure why we need a separate discussion.
We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Generating faster/tighter code for lambdas (or even closures) can be implemented as a separate task, the two aren't really interconnected, since the Groovy closure is so versatile to begin with.
-Jesper
发件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 23:10
收件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
On 7 Feb 2017, at 16.00, Daniel Sun <<a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738478&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
Cheers,
Daniel.Sun
发件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=0" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 22:23
收件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=1" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: [VOTE] Apache Groovy Roadmap<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://nabble.com/>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://Nabble.com>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738482.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738488.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
Gotcha 😊
For me, I don’t like two versions of lambda expression… it will confuse developers.
Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 23:44
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
On 7 Feb 2017, at 16.27, Daniel Sun <[hidden email]</user/SendEmail.jtp?type=node&node=5738482&i=0>> wrote:
To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
A real lambda expression is implemented in Java as an invokedynamic call which makes use of a bootstrap method calling into a class called the LambdaMetafactory (https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html) , and puts the body of the lambda expression into a hidden method on the class. The LambdaMetafactory sets up the magic class which holds any escaped variables and implements the functional interface. To work, it requires EXACT type information, so it's only possible to do this in static compilation.
* For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
I'm not sure why we need a separate discussion.
We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Generating faster/tighter code for lambdas (or even closures) can be implemented as a separate task, the two aren't really interconnected, since the Groovy closure is so versatile to begin with.
-Jesper
发件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 23:10
收件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
On 7 Feb 2017, at 16.00, Daniel Sun <<a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738478&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
Cheers,
Daniel.Sun
发件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=0" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 22:23
收件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=1" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: [VOTE] Apache Groovy Roadmap<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://nabble.com/>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://Nabble.com>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738482.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738484.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Jesper Steen Møller <je...@selskabet.org>.
> On 7 Feb 2017, at 16.27, Daniel Sun <re...@hotmail.com> wrote:
> To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
>
>
A real lambda expression is implemented in Java as an invokedynamic call which makes use of a bootstrap method calling into a class called the LambdaMetafactory (https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html <https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html>) , and puts the body of the lambda expression into a hidden method on the class. The LambdaMetafactory sets up the magic class which holds any escaped variables and implements the functional interface. To work, it requires EXACT type information, so it's only possible to do this in static compilation.
>
>
> For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
> I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
>
>
>
> I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
>
>
I'm not sure why we need a separate discussion.
We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Generating faster/tighter code for lambdas (or even closures) can be implemented as a separate task, the two aren't really interconnected, since the Groovy closure is so versatile to begin with.
-Jesper
>
>
> 发件人: [hidden email] <x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=0>
> 发送时间: 2017年2月7日 23:10
> 收件人: [hidden email] <x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=1>
> 主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
>
>
>
> (changing the subject so we don't disrupt the main discussion)
>
> Not quite 😔
>
> The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
>
> I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
>
> -Jesper
>
>> On 7 Feb 2017, at 16.00, Daniel Sun <[hidden email] <x-msg://13/user/SendEmail.jtp?type=node&node=5738478&i=0>> wrote:
>>
>> Hi Jochen,
>>
>>
>>
>> That’s great!
>>
>> Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
>>
>>
>>
>> Cheers,
>>
>> Daniel.Sun
>>
>>
>>
>> 发件人: <a href="x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
>> 发送时间: 2017年2月7日 22:23
>> 收件人: <a href="x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
>> 主题: Re: [VOTE] Apache Groovy Roadmap
>>
>>
>>
>>
>>
>> On 07.02.2017 14:44, Daniel Sun wrote:
>> > Hi Cédric,
>> >
>> > It seems that too many choices are a annoying problem, but I
>> > believe we can conquer it sooner or later ;)
>> > BTW, is it possible to keep groovy' lambda expression as it
>> > is(i.e. groovy closure with lambda syntax) but generate *real* lambda
>> > bytecode for
>> > it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java <https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java>)?
>>
>> sure, you should make a visitLambdaExpression similar to
>> visitClosureExpression and change our visitors
>>
>> bye Jochen
>>
>>
>> If you reply to this email, your message will be added to the discussion below:
>> http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html>
>> To unsubscribe from [VOTE] Apache Groovy Roadmap, click here <applewebdata://33D9FFB8-25E8-43A3-B0D7-C189440ABA6C>.
>> NAML <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>> View this message in context: 答复: [VOTE] Apache Groovy Roadmap <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
>> Sent from the Groovy Dev mailing list archive <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com <http://nabble.com/>.
>
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html>
> To unsubscribe from [VOTE] Apache Groovy Roadmap, click here <applewebdata://33D9FFB8-25E8-43A3-B0D7-C189440ABA6C>.
> NAML <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
> View this message in context: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap) <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html>
> Sent from the Groovy Dev mailing list archive <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com.
答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
* For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 23:10
收件人: Daniel Sun<ma...@hotmail.com>
主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
On 7 Feb 2017, at 16.00, Daniel Sun <[hidden email]</user/SendEmail.jtp?type=node&node=5738478&i=0>> wrote:
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
Cheers,
Daniel.Sun
发件人: <a href="x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 22:23
收件人: <a href="x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: [VOTE] Apache Groovy Roadmap<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://Nabble.com>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Jesper Steen Møller <je...@selskabet.org>.
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
> On 7 Feb 2017, at 16.00, Daniel Sun <re...@hotmail.com> wrote:
>
> Hi Jochen,
>
>
>
> That’s great!
>
> Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
>
>
>
> Cheers,
>
> Daniel.Sun
>
>
>
> 发件人: [hidden email] <x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0>
> 发送时间: 2017年2月7日 22:23
> 收件人: [hidden email] <x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1>
> 主题: Re: [VOTE] Apache Groovy Roadmap
>
>
>
>
>
> On 07.02.2017 14:44, Daniel Sun wrote:
> > Hi Cédric,
> >
> > It seems that too many choices are a annoying problem, but I
> > believe we can conquer it sooner or later ;)
> > BTW, is it possible to keep groovy' lambda expression as it
> > is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> > bytecode for
> > it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java <https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java>)?
>
> sure, you should make a visitLambdaExpression similar to
> visitClosureExpression and change our visitors
>
> bye Jochen
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html>
> To unsubscribe from [VOTE] Apache Groovy Roadmap, click here <applewebdata://B43F076E-4CE3-48E5-BE21-FA7C074BC8FF>.
> NAML <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
> View this message in context: 答复: [VOTE] Apache Groovy Roadmap <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
> Sent from the Groovy Dev mailing list archive <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com.
答复: [VOTE] Apache Groovy Roadmap
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime??
Cheers,
Daniel.Sun
发件人: Jochen Theodorou [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 22:23
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: [VOTE] Apache Groovy Roadmap
Posted by Jochen Theodorou <bl...@gmx.org>.
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi C�dric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
Re: [VOTE] Apache Groovy Roadmap
Posted by Cédric Champeau <ce...@gmail.com>.
2017-02-07 14:44 GMT+01:00 Daniel Sun <re...@hotmail.com>:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I believe
> we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it is(i.e.
> groovy closure with lambda syntax) but generate *real* lambda bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/
> org/codehaus/groovy/ast/expr/LambdaExpression.java)?
>
>
I'm not sure what you mean by "possible". Everything seems possible. To me
it's more a discussion of semantics. And I'm on the side that thinks we
should have the same semantics for closures and lambdas.
> Cheers,
> Daniel.Sun
>
>
>
> 在 Cédric Champeau [via Groovy] <ml-node+[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5738469&i=0>>，2017年2月7日
> 下午9:16写道：
>
> The result is that the vote turned into a debate again. I give up :)
>
> 2017-02-07 4:18 GMT+01:00 Daniel Sun <[hidden email]>:
>
>> Hi Cédric,
>>
>> 72h has gone. The result is ?
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> View this message in context: http://groovy.329449.n5.
>> nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-
> Roadmap-tp5738250p5738467.html
> To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
> NAML
> <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
>
> ------------------------------
> View this message in context: Re: [VOTE] Apache Groovy Roadmap
> <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738469.html>
> Sent from the Groovy Dev mailing list archive
> <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at
> Nabble.com.
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Daniel Sun <re...@hotmail.com>.
Hi Cédric,
It seems that too many choices are a annoying problem, but I believe we can conquer it sooner or later ;)
BTW, is it possible to keep groovy' lambda expression as it is(i.e. groovy closure with lambda syntax) but generate *real* lambda bytecode for it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
Cheers,
Daniel.Sun
在 Cédric Champeau [via Groovy] <ml...@n5.nabble.com>，2017年2月7日 下午9:16写道：
The result is that the vote turned into a debate again. I give up :)
2017-02-07 4:18 GMT+01:00 Daniel Sun <[hidden email]>:
Hi Cédric,
72h has gone. The result is ?
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738467.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738469.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: [VOTE] Apache Groovy Roadmap
Posted by Keith Suderman <su...@anc.org>.
I will let the PMC decide on the exact numbering and what goes where. However;
+1 on getting Macros and Parrot out the door and available in a 2.x compatible version as soon as possible.
> On Feb 7, 2017, at 9:59 AM, Jesper Steen Møller <je...@selskabet.org> wrote:
>
> Well, I didn't see many actually object to the contents or order that you suggested, but primarily the numbering. I'll give it another go.
>
> The vote thread seemed to raise three issues:
> 1) Whether or not to provide the parrot parser as a standalone option ASAP (this is actually quite a bit of work)
> 2) How to best design the semantics of lambda expressions in Groovy
> 3) How to deal with Groovy in JDK9 with or without breaking changes (i.e. still support Groovy 2.x in JDK9 WITHOUT Jigsaw, but only Groovy 3.x WITH Jigsaw, because of indy and new package names, which both break old classfiles and perhaps source).
>
> If we're very pedantic about semantic versions, we'll have to bump major numbers each time we raise the minimum runtime requirement. But - what if we're less pedantic? We could restate our semantic versioning interpretation to be that the 2.x line will be source code compatible with previous 2.x Groovy sources, but with higher JVM runtime environment requirements.
> I.e. you can still run your old Groovy-compiled classfiles with Groovy 2.x. So they're compatible, you just need a newer runtime...
> As for Parrot: It has been backported to 1.7, and while it would require testing, I can't see the reason for marking it a breaking change.
>
> I think we should raise these three discussion points as separate threads, and restart the vote, but with two flavours:
>
> YES-1:
> - Groovy 2.5: integrates macros and requires Java 7, to be released ASAP, we've been waiting for this for too long
> - Groovy 2.6: integrate Parrot, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate Jigsaw and drop old callsite caching + use indy. The only version with necessary breaking changes (we have no choice here)
>
> YES-2:
> - Groovy 3.0: integrates macros and requires Java 7, to be released ASAP, we've been waiting for this for too long
> - Groovy 3.1: integrate Parrot, implying backporting Parrot to Java 7
> - Groovy 4.0: integrate Jigsaw and drop old callsite caching + use indy. The only version with necessary breaking changes (we have no choice here)
>
> So what will it be:
>
> - [ ] YES-1, I approve the roadmap with the pragmatic stance to compatibility
> - [ ] YES-2, I approve the roadmap above with the stricter stance towards compatibility
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> In the end, it's for the PMC to decide.
>
> -Jesper
>
>
>> On 7 Feb 2017, at 14.15, Cédric Champeau <cedric.champeau@gmail.com <ma...@gmail.com>> wrote:
>>
>> The result is that the vote turned into a debate again. I give up :)
>>
>> 2017-02-07 4:18 GMT+01:00 Daniel Sun <realbluesun@hotmail.com <ma...@hotmail.com>>:
>> Hi Cédric,
>>
>> 72h has gone. The result is ?
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html>
>> Sent from the Groovy Dev mailing list archive at Nabble.com <http://nabble.com/>.
>>
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Jesper Steen Møller <je...@selskabet.org>.
Well, I didn't see many actually object to the contents or order that you suggested, but primarily the numbering. I'll give it another go.
The vote thread seemed to raise three issues:
1) Whether or not to provide the parrot parser as a standalone option ASAP (this is actually quite a bit of work)
2) How to best design the semantics of lambda expressions in Groovy
3) How to deal with Groovy in JDK9 with or without breaking changes (i.e. still support Groovy 2.x in JDK9 WITHOUT Jigsaw, but only Groovy 3.x WITH Jigsaw, because of indy and new package names, which both break old classfiles and perhaps source).
If we're very pedantic about semantic versions, we'll have to bump major numbers each time we raise the minimum runtime requirement. But - what if we're less pedantic? We could restate our semantic versioning interpretation to be that the 2.x line will be source code compatible with previous 2.x Groovy sources, but with higher JVM runtime environment requirements.
I.e. you can still run your old Groovy-compiled classfiles with Groovy 2.x. So they're compatible, you just need a newer runtime...
As for Parrot: It has been backported to 1.7, and while it would require testing, I can't see the reason for marking it a breaking change.
I think we should raise these three discussion points as separate threads, and restart the vote, but with two flavours:
YES-1:
- Groovy 2.5: integrates macros and requires Java 7, to be released ASAP, we've been waiting for this for too long
- Groovy 2.6: integrate Parrot, implying backporting Parrot to Java 7
- Groovy 3.0: integrate Jigsaw and drop old callsite caching + use indy. The only version with necessary breaking changes (we have no choice here)
YES-2:
- Groovy 3.0: integrates macros and requires Java 7, to be released ASAP, we've been waiting for this for too long
- Groovy 3.1: integrate Parrot, implying backporting Parrot to Java 7
- Groovy 4.0: integrate Jigsaw and drop old callsite caching + use indy. The only version with necessary breaking changes (we have no choice here)
So what will it be:
- [ ] YES-1, I approve the roadmap with the pragmatic stance to compatibility
- [ ] YES-2, I approve the roadmap above with the stricter stance towards compatibility
- [ ] NO, I do not approve the roadmap abobe beause...
- [ ] I don't mind, or this goes beyond what I can think of
In the end, it's for the PMC to decide.
-Jesper
> On 7 Feb 2017, at 14.15, Cédric Champeau <ce...@gmail.com> wrote:
>
> The result is that the vote turned into a debate again. I give up :)
>
> 2017-02-07 4:18 GMT+01:00 Daniel Sun <realbluesun@hotmail.com <ma...@hotmail.com>>:
> Hi Cédric,
>
> 72h has gone. The result is ?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html>
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Cédric Champeau <ce...@gmail.com>.
The result is that the vote turned into a debate again. I give up :)
2017-02-07 4:18 GMT+01:00 Daniel Sun <re...@hotmail.com>:
> Hi Cédric,
>
> 72h has gone. The result is ?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Paul King <pa...@asert.com.au>.
I kind of got the impression that the thread seemed to turn into a
discussion thread - but happy to be corrected if others didn't get
that impression.
My impression was that there was a lot of consensus around what we
want in the next "non-bugfix" release (e.g. macros and jdk 7+) but
some fuzziness for a few things (e.g. all/none/some of Parrot). I
think we just move towards getting the release ready for the things
that are clear and work on reducing the fuzziness in parallel. When
things are (more) ready, we can certainly do another more focused vote
on what features go where and what to call the release(s). With that
in mind, I have started reviewing the macros PR - I am liking what I
am seeing - but would be keen for someone else to join the party! :-)
Cheers, Paul.
On Tue, Feb 7, 2017 at 1:18 PM, Daniel Sun <re...@hotmail.com> wrote:
> Hi Cédric,
>
> 72h has gone. The result is ?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: [VOTE] Apache Groovy Roadmap
Posted by Daniel Sun <re...@hotmail.com>.
Hi Cédric,
72h has gone. The result is ?
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738451.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: [VOTE] Apache Groovy Roadmap
Posted by Andres Almiray <aa...@gmail.com>.
Having Parrot available for immediate testing is the reason why I'd
advocate for having 3.0-ea releases ;-)
-------------------------------------------
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Tue, Jan 31, 2017 at 9:50 AM, Søren Berg Glasius <so...@glasius.dk>
wrote:
> YES (not binding). This is a clear plan, and is easy to understand for the
> community.
>
> It makes way for a 2.5 soon, and it also puts Parrot in a release that is
> not too far into the future, which IMO is important.
>
> IMO a good plan.
>
> On Tue, 31 Jan 2017 at 09:45 Cédric Champeau <cc...@apache.org> wrote:
>
>> YES for me too (forgot to answer :D). And yes, we should review (and
>> merge) your PR before beta-1.
>>
>> 2017-01-31 <20%2017%2001%2031> 9:44 GMT+01:00 Sergei Egorov <
>> bsideup@gmail.com>:
>>
>> YES from me.
>>
>> Would be great if we can deliver #1 as a macro method, not it form of
>> "MacroGroovy" (and hopefully forget this awkward name collision :D )
>>
>> Just want to remind that there is a PR waiting for a review where I
>> rewrote it and implemented basic macro methods support:
>> https://github.com/apache/groovy/pull/472/files
>>
>>
>> BR,
>> Sergei
>>
>> On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau <cc...@apache.org>
>> wrote:
>>
>> Hi guys,
>>
>> There are multiple conversations going on for weeks, and I think they are
>> going nowhere. We could discuss for months what's the best plan for Groovy,
>> without releasing anything. Here are the challenges that are waiting for us:
>>
>> 1. release a version of Groovy that integrates Groovy macros
>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
>> required to smoothly transition to higher requirements (and also, make our
>> devs lives easier)
>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
>> drop the old call site caching and use indy Groovy everywhere
>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>
>> I would like to propose the following plan:
>>
>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
>> for this for too long
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
>> changes (we have no choice here)
>>
>> This plan is, I think, a good compromise for all the requirements we
>> have: backwards compatibility, and making progress and not having too many
>> branches. An alternative would be to keep Parrot on Java 8, but as some of
>> us have said, this is incompatible with a soonish release. The drawback is
>> that Parrot has the risk of being a breaking change (it is, typically if
>> people implicitly depend on the old parser, which would be bad), so there's
>> a risk of not following semantic versioning.
>>
>> - [ ] YES, I approve the roadmap above
>> - [ ] NO, I do not approve the roadmap abobe beause...
>> - [ ] I don't mind, or this goes beyond what I can think of
>>
>> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>>
>>
>> --
> Best regards / Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88 <+45%2040%2044%2091%2088>, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Søren Berg Glasius <so...@glasius.dk>.
YES (not binding). This is a clear plan, and is easy to understand for the
community.
It makes way for a 2.5 soon, and it also puts Parrot in a release that is
not too far into the future, which IMO is important.
IMO a good plan.
On Tue, 31 Jan 2017 at 09:45 Cédric Champeau <cc...@apache.org> wrote:
> YES for me too (forgot to answer :D). And yes, we should review (and
> merge) your PR before beta-1.
>
> 2017-01-31 <20%2017%2001%2031> 9:44 GMT+01:00 Sergei Egorov <
> bsideup@gmail.com>:
>
> YES from me.
>
> Would be great if we can deliver #1 as a macro method, not it form of
> "MacroGroovy" (and hopefully forget this awkward name collision :D )
>
> Just want to remind that there is a PR waiting for a review where I
> rewrote it and implemented basic macro methods support:
> https://github.com/apache/groovy/pull/472/files
>
>
> BR,
> Sergei
>
> On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau <cc...@apache.org>
> wrote:
>
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make our
> devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
>
> --
Best regards / Med venlig hilsen,
Søren Berg Glasius
Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.
Re: [VOTE] Apache Groovy Roadmap
Posted by Cédric Champeau <cc...@apache.org>.
YES for me too (forgot to answer :D). And yes, we should review (and merge)
your PR before beta-1.
2017-01-31 9:44 GMT+01:00 Sergei Egorov <bs...@gmail.com>:
> YES from me.
>
> Would be great if we can deliver #1 as a macro method, not it form of
> "MacroGroovy" (and hopefully forget this awkward name collision :D )
>
> Just want to remind that there is a PR waiting for a review where I
> rewrote it and implemented basic macro methods support:
> https://github.com/apache/groovy/pull/472/files
>
>
> BR,
> Sergei
>
> On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau <cc...@apache.org>
> wrote:
>
>> Hi guys,
>>
>> There are multiple conversations going on for weeks, and I think they are
>> going nowhere. We could discuss for months what's the best plan for Groovy,
>> without releasing anything. Here are the challenges that are waiting for us:
>>
>> 1. release a version of Groovy that integrates Groovy macros
>> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
>> required to smoothly transition to higher requirements (and also, make our
>> devs lives easier)
>> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
>> drop the old call site caching and use indy Groovy everywhere
>> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
>> 5. compatibility with Jigsaw, aka "Groovy as a module"
>>
>> I would like to propose the following plan:
>>
>> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
>> for this for too long
>> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
>> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
>> changes (we have no choice here)
>>
>> This plan is, I think, a good compromise for all the requirements we
>> have: backwards compatibility, and making progress and not having too many
>> branches. An alternative would be to keep Parrot on Java 8, but as some of
>> us have said, this is incompatible with a soonish release. The drawback is
>> that Parrot has the risk of being a breaking change (it is, typically if
>> people implicitly depend on the old parser, which would be bad), so there's
>> a risk of not following semantic versioning.
>>
>> - [ ] YES, I approve the roadmap above
>> - [ ] NO, I do not approve the roadmap abobe beause...
>> - [ ] I don't mind, or this goes beyond what I can think of
>>
>> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>>
>>
Re: [VOTE] Apache Groovy Roadmap
Posted by Sergei Egorov <bs...@gmail.com>.
YES from me.
Would be great if we can deliver #1 as a macro method, not it form of
"MacroGroovy" (and hopefully forget this awkward name collision :D )
Just want to remind that there is a PR waiting for a review where I rewrote
it and implemented basic macro methods support:
https://github.com/apache/groovy/pull/472/files
BR,
Sergei
On Tue, Jan 31, 2017 at 10:37 AM Cédric Champeau <cc...@apache.org>
wrote:
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make our
> devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Daniel Sun <re...@hotmail.com>.
Hi Suderman,
> Hopefully Parrot doesn't break anything, but I don't know if that can be
> asserted definitively at this point.
Parrot passes all tests of Apache Groovy, so it conforms to GLS. In
addition, Parrot can parse source code of Grails, Gradle, Spock, Geb. But I
still hope your program conforms to GLS too ;)
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738282.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: [VOTE] Apache Groovy Roadmap
Posted by Suderman Keith <su...@anc.org>.
No.
I would like to vote YES as this is almost what I proposed in the "release process" thread, but I think I'm going to have to vote NO as there are potential breaking changes in 2.5 (requiring Java 1.7) and 2.6 (switching to Parrot). Hopefully Parrot doesn't break anything, but I don't know if that can be asserted definitively at this point.
Keith
> On Jan 31, 2017, at 3:37 AM, Cédric Champeau <cc...@apache.org> wrote:
>
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are going nowhere. We could discuss for months what's the best plan for Groovy, without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is required to smoothly transition to higher requirements (and also, make our devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have: backwards compatibility, and making progress and not having too many branches. An alternative would be to keep Parrot on Java 8, but as some of us have said, this is incompatible with a soonish release. The drawback is that Parrot has the risk of being a breaking change (it is, typically if people implicitly depend on the old parser, which would be bad), so there's a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Andres Almiray <aa...@gmail.com>.
In principle I'd say YES but I don't agree on Parrot being backported to
2.6 due to potential incompatibilities. I don't want users to have the same
pain we had when switching between Groovy 1.7 and 1.8.
IMHO Parrot should go on 3.x, thus the only parts of the roadmap I can
safely vote YES are #1 and #3. Given the set of voting options we've got my
vote is NO.
My proposed roadmap would be then
- Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
for this for too long
- Groovy 3.0: integrate 3, 4 and 5. The only version with necessary
breaking changes (we have no choice here)
Cheers,
Andres
-------------------------------------------
Java Champion; Groovy Enthusiast
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Tue, Jan 31, 2017 at 9:37 AM, Cédric Champeau <cc...@apache.org>
wrote:
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make our
> devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
>
Re: [VOTE] Apache Groovy Roadmap
Posted by Guillaume Laforge <gl...@gmail.com>.
YES (binding)
On Tue, Jan 31, 2017 at 9:37 AM, Cédric Champeau <cc...@apache.org>
wrote:
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they are
> going nowhere. We could discuss for months what's the best plan for Groovy,
> without releasing anything. Here are the challenges that are waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make our
> devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us to
> drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting
> for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary breaking
> changes (we have no choice here)
>
> This plan is, I think, a good compromise for all the requirements we have:
> backwards compatibility, and making progress and not having too many
> branches. An alternative would be to keep Parrot on Java 8, but as some of
> us have said, this is incompatible with a soonish release. The drawback is
> that Parrot has the risk of being a breaking change (it is, typically if
> people implicitly depend on the old parser, which would be bad), so there's
> a risk of not following semantic versioning.
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [VOTE] Apache Groovy Roadmap
Posted by Bahman Movaqar <Ba...@BahmanM.com>.
On 01/31/2017 09:37 AM, Cédric Champeau wrote:
> Hi guys,
>
> There are multiple conversations going on for weeks, and I think they
> are going nowhere. We could discuss for months what's the best plan for
> Groovy, without releasing anything. Here are the challenges that are
> waiting for us:
>
> 1. release a version of Groovy that integrates Groovy macros
> 2. upgrade the minimal runtime required for Groovy to 1.7, which is
> required to smoothly transition to higher requirements (and also, make
> our devs lives easier)
> 3. upgrade the minimal runtime required for Groovy to 1.8, allowing us
> to drop the old call site caching and use indy Groovy everywhere
> 4. integrate Parrot, which replaces the use of Antlr2 with Antlr4
> 5. compatibility with Jigsaw, aka "Groovy as a module"
>
> I would like to propose the following plan:
>
> - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been
> waiting for this for too long
> - Groovy 2.6: integrate 4, implying backporting Parrot to Java 7
> - Groovy 3.0: integrate 3 and 5. The only version with necessary
> breaking changes (we have no choice here)
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
YES.
Just a side note: Doing 2 in a minor release (2.4 -> 2.5) breaks
backward compatibility --I'd personally rather see such changes in a
major version bump. On the other hand, JRE6 is (should be) history now,
so this really doesn't matter :-)
--
Bahman Movaqar
http://BahmanM.com - https://twitter.com/bahman__m
https://github.com/bahmanm - https://gist.github.com/bahmanm
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Re: [VOTE] Apache Groovy Roadmap
Posted by Russel Winder <ru...@winder.org.uk>.
On Tue, 2017-01-31 at 09:37 +0100, Cédric Champeau wrote:
> […]
>
> - [ ] YES, I approve the roadmap above
> - [ ] NO, I do not approve the roadmap abobe beause...
> - [ ] I don't mind, or this goes beyond what I can think of
>
> This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017.
YES
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder