groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Steen Møller <>
Subject Re: Breaking changes in 3.0 [was: Re: 2.5.0-rc-3]
Date Thu, 24 May 2018 09:12:29 GMT
On 23 May 2018, at 13.24, Cédric Champeau <> 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:


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?


> Le mer. 23 mai 2018 à 13:11, Jesper Steen Møller < <>>
a écrit :
> > On 23 May 2018, at 12.23, Russel Winder < <>>
> > 
> > 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
> 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

View raw message