You can have breaking changes in the way the classes are seen from Java (and jigsaw) without having breaking changes when you use these classes from Groovy.
By example, you can introduce a way to create type aliases to Groovy, given that, you can move Java classes around and keep the same references in the Groovy code.

This would work only if a library is recompiled against the latest Groovy version (and even more true if you use @CompileStatic), whereas the idea of backwards compatibility is *not* to recompile everything. That is to say, take Groovy N+1 and it is capable of running classes compiled with Groovy N.
Also about groovy-all, you can create a module groovy-all that will require all other modules, no ?

Yes, but that's not the purpose of this module today. It's more for guys who are too lazy to precisely determine all their Groovy module dependencies and prefer to use groovy-all instead of groovy + "find all modules that I use". Note that the simplification that I give is recent, because a few releases ago, groovy-all contained repackaged ASM classes, whereas groovy.jar did not. Now both have repackaged classes, making it much more consistent and even less useful to use groovy-all.


De: "Cédric Champeau" <>
Envoyé: Jeudi 26 Novembre 2015 13:10:11
Objet: Re: challenges through Java modules (aka jigsaw)

So I'm taking advantage of a bit of free time to write a quick summary of the situation and what we will have to decide. Basically, we have a serious problem (but we will not be the only ones).

When you declare a Jigsaw module, one has to declare the list of packages that it exports (and sub-packages are not exported). Those packages are the ones that can be consumed from other Jigsaw modules. It therefore implements strong encapsulation, but making it impossible to reference an internal class of a module, both at compile time and runtime. So far so good. The problem is that the list of packages that belong to a module is exclusive to that module. So if module A exports "", another module cannot do the same, or it will fail whenever the 2 modules are loaded at the same time. Worse, *internal packages* are also exclusive, so even if you don't export a package, two modules containing the same internal packages will *also* fail.

Why is it a problem for Groovy? It is a problem because we have a very long history. And part of this history makes that modularization was introduced pretty recently, in the 2.0 release. Before, Groovy only had a single module. Now Groovy provides multiple modules, but also a "groovy-all" jar that contains all the classes from all modules. At this point, we can already see that this won't be possible anymore: groovy-all must die, or we must not support modules (sigh). But the problem is even worse. Since the split into modules was done late and that we wanted to preserve backwards compatibility, we decided not to change the packages of classes extracted into their own modules. So for example, XmlParser is found in groovy.util (not groovy.util.xml) in the groovy-xml module, but we also have lots of classes that live into groovy.xml into the "groovy" core module. So in short, our modules are no fit for Jigsaw: we must come back to the very bad state of having everything in a single module.

Of course, that's not a satisfactory solution, and of course, there's nothing we can do to influence the decision not to make such a strong requirement: there are technical reasons behind this choice.

So what can we do?

1. the easiest, fastest path, is to kill all modules that we have today, and go with a single, good old, groovy-all jar. We would go years backwards, and it's definitely not something we want to do. We want to have *more* modularization, in particular for Android, where the current split is still too big.
2. refactor modules so that each module has its own set of packages, and hope that we don't end up with a big groovy-all jar. Seems very unlikely.
3. break binary compatibility, move classes around, reorganize stuff.

Despite my worst nightmare of fragmenting the community (that is what happened for all languages that tried to introduce breaking changes), I think we don't have the choice and we have to go route 3. And if we do so, I would take advantage of this fact to:
1. reorganize our code base even further to separate everything into their own modules and make them as minimal as possible
2. migrate to Java 8 as the minimum JDK version, which would allow us to drop support of the old call site caching, get a new MOP, and possibly removing everything that annoys us in terms of behavior which is kept for the sake of compatibility

It's a long road, and it is pretty obvious that we won't be able to be ready for Jigsaw launch (october 2016), but it we don't decide today what we want to do, we will soon be obsolete, because nobody will be able to use Groovy with Jigsaw.

Last but not least, as part of the Gradle team, I'd like to take advantage of this to rework our build to make it more consistent, faster, and aimed towards the future. In next January, we will start promoting a smooth migration path to Jigsaw using the Java software model. I think Groovy is still too big to migrate now to the java software model, but at least, we can start investigating. It is crucial to us because Gradle uses Groovy internally, so if Gradle doesn't run on Jigsaw, we will have a medium term problem (medium, because we could still run on JDK 8 but target JDK 9).

Let the fun begin!

2015-11-15 17:07 GMT+01:00 Jochen Theodorou <>:
On 15.11.2015 12:11, Cédric Champeau wrote:
Hi guys,

After spending some days at Devoxx, I had a few chats about Jigsaw and
the implications on Groovy. I will send an email summarizing them and I
think we need to come up with a plan.

I was saying that, yes. Seems nobody wanted to believe me

I'm not sure JIRA is the best way
to track this, but in short, we have serious issues coming, and breaking
changes. Maybe it's a chance for us to make all the breaking changes we
thought for so long.

I doubt it, we don't have the manpower, but we can do a bit of course

bye Jochen