incubator-groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: challenges through Java modules (aka jigsaw)
Date Thu, 26 Nov 2015 12:10:11 GMT
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 "foo.bar", 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 <blackdrag@gmx.org>:

> 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
>
>
>

Mime
View raw message