You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Jesper Steen Møller <je...@selskabet.org> on 2018/05/23 11:11:15 UTC
Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
> On 23 May 2018, at 12.23, Russel Winder <ru...@winder.org.uk> wrote:
>
> On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote:
>> No plans to go to 18/19 model at this stage.
>>
>> If we push for an early 3.0, some of the breaking changes will have to be
>> deferred.
>> A very quick release after 3.0 could easily be a 3.1 if it was needed.
>>
>> The next major release (4.0) would be when we had tackled (a significant
>> chunk of) the remaining breaking changes.
>>
>
> I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per se.
>
> In the current climate is a 3.0 now, 4.0 in the next year actually a problem?
>
> Given the very volunteer nature of the Groovy project, pragmatism more than
> anything has to be the order of the day. However I think there is a marketing
> element here. Having new 2.4.X releases doesn't really achieve anything
> marketing-wise. Releasing 2.5.0 actually doesn't much either really, though
> clearly we do it as we are already at RC-3, and it can be "milked". But 2.5 is
> just backward compatible extensions to 2.4, is this Groovy actually
> progressing?
>
> I suggest we want to get a 3.0 out to show Groovy is progressing and with some
> breaking changes, in particular JDK8+ only, not to mention a parser based on
> somewhat newer technology! "Groovy drops support for JDK7" is probably a good
> thing marketing wise.
>
> My feeling is that Groovy does not have enough resource to go for big major
> version number releases, but that it needs something to combat the "it's old
> technology" feel given the rise of Kotlin. I'd push for a 3.0 release soon and
> worry about the metamodel changes later – unless they are already in place?
>
I agree with the soft factors around numbering.
As I understand, the metamodel changes are not in place yet, and not on anybody's immediate schedule.
A) However, as I understand it, MOP2 could be made backwards compatible, so that a new MOP2 runtime could still honor the MOP1 protocol, from some version 3.x onwards. We could then deprecate the MOP1 way of doing things.
B) As for the indy stuff, we should choose to produce indy-only bytecodes now that we require Java 8 for Groovy 3.0. Again, we still need runtime support for the existing CallSite caching, or we'd have to force everybody to recompile every Groovy library they use. That's hardly a good idea!
C) Finally, for 3.0 we could switch generation of closures to be bootstrap-driven, i.e. by keeping the closure body as a method of the enclosing class, but by generating the closure in the fashion of LambdaMetafactory. That way, we would keep the Groovy semantics, but reduce the cost of using closures (all those extra classfiles). We could possibly introduce a ClosureInterface for forwards compatibility, and deprecate the use of the Closure class directly.
Then, in some future majorversion 4.0, we could stop supporting MOP1, we could drop support for the old callsite caching, and we could make
Was that about right?
-Jesper
Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Posted by Jesper Steen Møller <je...@selskabet.org>.
On 23 May 2018, at 13.24, Cédric Champeau <ce...@gmail.com> wrote:
>
> +1, regarding indy by default, I wonder if we could provide the "old" MOP as a backward compatibility runtime jar...
>
Yes, but that would be pretty tricky if we want to target JPMS too, due to split packages.
I wonder if it'd be possible to split it all up into (JPMS) modules like this:
groovy-core
groovy-compiler
groovy-xml
groovy-cli
...
And then provide a "Groovy 2.x" compatibility JARs for stuff like MOP1 compatibility, modules that have moved, etc. and provide that in the groovy-all jar?
-Jesper
> Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller <jesper@selskabet.org <ma...@selskabet.org>> a écrit :
>
> > On 23 May 2018, at 12.23, Russel Winder <russel@winder.org.uk <ma...@winder.org.uk>> wrote:
> >
> > On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote:
> >> No plans to go to 18/19 model at this stage.
> >>
> >> If we push for an early 3.0, some of the breaking changes will have to be
> >> deferred.
> >> A very quick release after 3.0 could easily be a 3.1 if it was needed.
> >>
> >> The next major release (4.0) would be when we had tackled (a significant
> >> chunk of) the remaining breaking changes.
> >>
> >
> > I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per se.
> >
> > In the current climate is a 3.0 now, 4.0 in the next year actually a problem?
> >
> > Given the very volunteer nature of the Groovy project, pragmatism more than
> > anything has to be the order of the day. However I think there is a marketing
> > element here. Having new 2.4.X releases doesn't really achieve anything
> > marketing-wise. Releasing 2.5.0 actually doesn't much either really, though
> > clearly we do it as we are already at RC-3, and it can be "milked". But 2.5 is
> > just backward compatible extensions to 2.4, is this Groovy actually
> > progressing?
> >
> > I suggest we want to get a 3.0 out to show Groovy is progressing and with some
> > breaking changes, in particular JDK8+ only, not to mention a parser based on
> > somewhat newer technology! "Groovy drops support for JDK7" is probably a good
> > thing marketing wise.
> >
> > My feeling is that Groovy does not have enough resource to go for big major
> > version number releases, but that it needs something to combat the "it's old
> > technology" feel given the rise of Kotlin. I'd push for a 3.0 release soon and
> > worry about the metamodel changes later – unless they are already in place?
> >
>
> I agree with the soft factors around numbering.
>
>
> As I understand, the metamodel changes are not in place yet, and not on anybody's immediate schedule.
>
> A) However, as I understand it, MOP2 could be made backwards compatible, so that a new MOP2 runtime could still honor the MOP1 protocol, from some version 3.x onwards. We could then deprecate the MOP1 way of doing things.
>
> B) As for the indy stuff, we should choose to produce indy-only bytecodes now that we require Java 8 for Groovy 3.0. Again, we still need runtime support for the existing CallSite caching, or we'd have to force everybody to recompile every Groovy library they use. That's hardly a good idea!
>
> C) Finally, for 3.0 we could switch generation of closures to be bootstrap-driven, i.e. by keeping the closure body as a method of the enclosing class, but by generating the closure in the fashion of LambdaMetafactory. That way, we would keep the Groovy semantics, but reduce the cost of using closures (all those extra classfiles). We could possibly introduce a ClosureInterface for forwards compatibility, and deprecate the use of the Closure class directly.
>
> Then, in some future majorversion 4.0, we could stop supporting MOP1, we could drop support for the old callsite caching, and we could make
>
> Was that about right?
>
> -Jesper
>
>
Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Posted by Paul King <pa...@asert.com.au>.
yes, performance is one of the things we need to look at
On Thu, May 24, 2018 at 12:24 AM, Daniel.Sun <su...@apache.org> wrote:
> > I wonder if we could provide the "old" MOP as a backward compatibility
> runtime jar...
>
> +1
>
> P.S. when indy is enabled by default, Groovy's performance goes worse...
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Posted by "Daniel.Sun" <su...@apache.org>.
> I wonder if we could provide the "old" MOP as a backward compatibility
runtime jar...
+1
P.S. when indy is enabled by default, Groovy's performance goes worse...
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Posted by Cédric Champeau <ce...@gmail.com>.
+1, regarding indy by default, I wonder if we could provide the "old" MOP
as a backward compatibility runtime jar...
Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller <je...@selskabet.org> a
écrit :
>
> > On 23 May 2018, at 12.23, Russel Winder <ru...@winder.org.uk> wrote:
> >
> > On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote:
> >> No plans to go to 18/19 model at this stage.
> >>
> >> If we push for an early 3.0, some of the breaking changes will have to
> be
> >> deferred.
> >> A very quick release after 3.0 could easily be a 3.1 if it was needed.
> >>
> >> The next major release (4.0) would be when we had tackled (a significant
> >> chunk of) the remaining breaking changes.
> >>
> >
> > I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per
> se.
> >
> > In the current climate is a 3.0 now, 4.0 in the next year actually a
> problem?
> >
> > Given the very volunteer nature of the Groovy project, pragmatism more
> than
> > anything has to be the order of the day. However I think there is a
> marketing
> > element here. Having new 2.4.X releases doesn't really achieve anything
> > marketing-wise. Releasing 2.5.0 actually doesn't much either really,
> though
> > clearly we do it as we are already at RC-3, and it can be "milked". But
> 2.5 is
> > just backward compatible extensions to 2.4, is this Groovy actually
> > progressing?
> >
> > I suggest we want to get a 3.0 out to show Groovy is progressing and
> with some
> > breaking changes, in particular JDK8+ only, not to mention a parser
> based on
> > somewhat newer technology! "Groovy drops support for JDK7" is probably
> a good
> > thing marketing wise.
> >
> > My feeling is that Groovy does not have enough resource to go for big
> major
> > version number releases, but that it needs something to combat the "it's
> old
> > technology" feel given the rise of Kotlin. I'd push for a 3.0 release
> soon and
> > worry about the metamodel changes later – unless they are already in
> place?
> >
>
> I agree with the soft factors around numbering.
>
>
> As I understand, the metamodel changes are not in place yet, and not on
> anybody's immediate schedule.
>
> A) However, as I understand it, MOP2 could be made backwards compatible,
> so that a new MOP2 runtime could still honor the MOP1 protocol, from some
> version 3.x onwards. We could then deprecate the MOP1 way of doing things.
>
> B) As for the indy stuff, we should choose to produce indy-only bytecodes
> now that we require Java 8 for Groovy 3.0. Again, we still need runtime
> support for the existing CallSite caching, or we'd have to force everybody
> to recompile every Groovy library they use. That's hardly a good idea!
>
> C) Finally, for 3.0 we could switch generation of closures to be
> bootstrap-driven, i.e. by keeping the closure body as a method of the
> enclosing class, but by generating the closure in the fashion of
> LambdaMetafactory. That way, we would keep the Groovy semantics, but reduce
> the cost of using closures (all those extra classfiles). We could possibly
> introduce a ClosureInterface for forwards compatibility, and deprecate the
> use of the Closure class directly.
>
> Then, in some future majorversion 4.0, we could stop supporting MOP1, we
> could drop support for the old callsite caching, and we could make
>
> Was that about right?
>
> -Jesper
>
>
>