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 Sat, 28 Nov 2015 09:21:41 GMT
2015-11-28 9:12 GMT+01:00 Thibault Kruse <>:

> Given the funding of groovy changed last year, this situation will show
> what kind of support exists. I know my PRs are growing long beards.

Yeah, a large proportion of your PRs are tricky because they *might*
involve breaking changes. If we choose the breaking change way for Groovy
3, then it's not a problem anymore. Furthermore, I am much in favor of
rewritten modules for groovy console for example. One of the advantages of
going Apache is that we now have much more contributors and committers, I'm
pretty sure we can organize ourselves so that we have "subprojects" and can
work in parallel on topics that we are interested in.

> Maybe work on this could be modularized in smaller milestones, and be
> pursues over kickstarter or GSoC.
I don't think it's a very sane thing to rely on a kickstarter for an Apache
project, but why not.

> Also I remember another discussion where I put forward the idea of
> reducing the core codebase. Meaning to split out things like groovysh.
Oh yes. The smaller core, the better.

> It's not ideal maybe, but this might be a 'pick the lesser of two evils'
> situation.
> On Thursday, November 26, 2015, Guillaume Laforge <>
> wrote:
>> 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 <
>>> wrote:
>>> 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
>>>>> *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
>>>>> 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 <>
>> Blog:
>> Social: @glaforge <> / Google+
>> <>

View raw message