groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: Maven coordinates going forward
Date Thu, 30 Mar 2017 14:07:55 GMT
OK, in my mind that is perfectly fine. In this case the change of package name and Maven coordinates
is required, but in this case it is a good thing. It’s a good thing because you are saying
explicitly that both Groovy versions can co-exist, which is what separate packages and separate
Maven coordinates allow you to do. As an example of how this was done very well I think of
Jackson 1.x to 2.x where they can co-exist and use different packages/Maven coordinates. And
also in my mind, it’s acceptable as an upgrade scenario because I can use legacy libraries
not upgraded to Groovy 3 by treating them as I would any other JVM class, with just the decision
of having extra overhead by having both Groovy 2 and Groovy 3 in my classpath.

I suppose there would need to be some compatibility layer though because of things like Closure
being an abstract class, presumably Groovy 3 would have its own Closure type so there would
need to be a converter/wrapper to pass a G3 closure into a G2 class taking groovy.lang.Closure,
unless groovy.lang.Closure is not going to change for G3. It sounds like worst-case these
problems are solvable via a special Groovy 2-compat library that maybe excludes groovy.lang.Closure
so that it defers to the G3 implementation.


From: Cédric Champeau []
Sent: Thursday, March 30, 2017 9:18 AM
Subject: Re: Maven coordinates going forward

And again, _we have no choice_. If we want Groovy to run as a module, we HAVE to break binary
compatibility. There's absolutely no other way around. It's a thing. If we don't want to break
it, Groovy will never run as a module. And if JDK 9 modules become legion, then Groovy would

2017-03-30 15:16 GMT+02:00 Cédric Champeau <<>>:
To me the idea would be to be able to run Groovy 2 and Groovy NG concurrently.

2017-03-30 15:12 GMT+02:00 Winnebeck, Jason <<>>:
Can you explain the story around a library like<>tp-builder:http-builder,
which is no longer really maintained? What happens to such a library when Groovy 3 comes out
and we are using that library? Let's say there is no maintainer to update the sources to Groovy
3 and re-release.


-----Original Message-----
From: Russel Winder [<>]
Sent: Thursday, March 30, 2017 3:54 AM
Subject: Re: Maven coordinates going forward
On Thu, 2017-03-30 at 09:26 +0200, Cédric Champeau wrote:
> We have to keep in mind that there's a larger story here, which is
> supporting Groovy as a module. And this *will* require package changes
> and binary breaking changes. So I don't think the status quo is
> acceptable in the long run.

So why not make Groovy 3 the place to do this?

Whatever has been said about the Python situation, the core problem was not the breaking change,
the problem was the lack of active management of the change.

Python is a source deployment language where JRE-based langauges are not. Thus JRE-based application
have the classic COBOL, FORTRAN, and Fortran problem of "we've lost the source" (banks and
governments are the usual suspects for this). I would exclude this situation from our thinking.
Organisations in such a state (as some UK banks and the UK government is) should take it as
an opportunity to revolutionise (which the UK government is, cf. the job adverts for COBOL,
FORTRAN and Fortran knowledgeable people who also know Python, Java, etc.

Python also had the problem of Python 2.6 and 2.7 along with 3.3 and
3.4 (3.0, 3.1 and 3.2 can safely be ignored now). Having 2.6 and 3.3 in the mix made for a
very hard time. Allowing only 2.7 and 3.4+ in the mix made for a much, much easier time. So
initially moving from Python
2 to Python 3 was a manual task (bad management by the Python 3 folk), then came the six generation
of upgrade tooling (a start). By dropping
2.6 and 3.3, we get the far nicer future upgrade tooling (which works nicely to create 2.7
and 3.4+ compatible code). The moral here is choose the versions being upgraded from and to,
and then make some nice automation.

So if we assume a base of Groovy 2.4 and ignore all previous Groovys and the breaking change
of 3.0 can we write some Groovy (obviously :-) scripts that automate source changes?

If the Python 2 → Python 3 breaking change had been more actively managed with earlier arrival
of six and future, the problems would have been much less. Most of the vocal Python 2 Remainers
have now made their codes run on both Python 2 and Python 3, and there are very few complaints
about providing Python 3 only. OK so there are still a few people who say "we must support
Python 2.5" but those people are few and far between and are, in the main, totally ignored.
Python 4 will undoubtedly have breaking changes, but they will be better managed in terms
of supporting multi-version working and automated (well at least
semi-automated) upgrading and mixed-version working. The lessons of six and future have been
well learned.

So Groovy will have breaking changes, this is right and proper. Put in place tools for upgrading,
and support multi-version working where possible and practical. Do not be swayed by calls
for "we must change nothing, backward compatibility". They have a version of Groovy that works
for them so they should not upgrade – ever again. That must not stop the rest of us from

Dr Russel Winder      t: +44 20 7585 2200<tel:+44%2020%207585%202200>   voip:<>
41 Buckmaster Road    m: +44 7770 465 077<tel:%2B44%207770%20465%20077>   xmpp:<>
London SW11 1EN, UK   w:<>  skype: russel_winder
This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.

View raw message