groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <>
Subject Re: challenges through Java modules (aka jigsaw)
Date Thu, 26 Nov 2015 12:39:57 GMT
Hi Cendric, 

I'm not sure it's a good idea to introduce breaking changes in Groovy, 
as an anecdote, yesterday, i've started my day by converting a build script written in Python
from 2 to 3, it was still not working at noon, so we decide to convert it to Gradle ... 

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. 

Also about groovy-all, you can create a module groovy-all that will require all other modules,
no ? 


----- Mail original -----

> 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