groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Laforge <>
Subject Re: challenges through Java modules (aka jigsaw)
Date Thu, 26 Nov 2015 20:05:56 GMT
I'm also thinking it's the right moment to "fix" things we've done wrong,
have a clean separation, not leaking implementation, etc.
That's feeling like the right moment to seize this opportunity. We wouldn't
keep the odd location of some of the classes we've already mentioned. And
as Cédric says, we could also offer a converter in a way or another to help
the migration.
People fear transitions like Python 2 to 3 would happen as soon as we break
compatibility, but the differences between Python 2 and 3 were much bigger
that what we're speaking about here.

On Thu, Nov 26, 2015 at 8:49 PM, Cédric Champeau <>

> Honestly I don't think 1 or 2 is reasonable. The simple example of XML is
> enough to show the damage. We won't be able to have a separate XML module.
> That defeats the concepts of modules. Also it would lead to bigger jars,
> which is something we want to avoid as much as possible. Last but not
> least, the more I think about it, the more I think it's the event that we
> were all waiting for to finally do the breaking changes we've thought of
> for years. Eventually, we could come up with a smoother migration path, by
> providing an automatic source converter (remapping packages). It would have
> the same advantages as the ones Rémi talked about.
> 2015-11-26 19:18 GMT+01:00 Pascal Schumacher <>:
>> Thanks for the detailed analysis Cédric. :)
>> Am 26.11.2015 um 13:10 schrieb Cédric Champeau:
>>> 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.
>> Am 26.11.2015 um 14:16 schrieb Jochen Theodorou:
>>> I think we should concentrate on solving the package name conflicts in
>>> the new module system first... which basically is route 2. I am pretty sure
>>> the jdk9 problems won't end there and we need time to solve these problems
>>> as well... Of course we could still think about getting rid of the callsite
>>> caching part and depend on say JDK7 as minimum version.
>> I agree, we should try option 2 or - if it's nearly the same as option 1
>> - take option 1.
>> I think option 3 is the worst. With our current lack of resources I doubt
>> that we could implement enough "killer" features to motivate people to
>> update (getting people to update would be difficult anyway).
>> Cheers,
>> Pascal

Guillaume Laforge
Apache Groovy committer & PMC member
Product Ninja & Advocate at Restlet <>

Social: @glaforge <> / Google+

View raw message