groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <>
Subject Re: challenges through Java modules (aka jigsaw)
Date Thu, 26 Nov 2015 12:49:18 GMT
> 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.

> regards,
> Rémi
> ------------------------------
> *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

View raw message