groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <>
Subject Re: challenges through Java modules (aka jigsaw)
Date Sat, 28 Nov 2015 08:12:02 GMT
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. Maybe
work on this could be modularized in smaller milestones, and be pursues
over kickstarter or GSoC.

Also I remember another discussion where I put forward the idea of reducing
the core codebase. Meaning to split out things like groovysh.

It's not ideal maybe, but this might be a 'pick the lesser of two evils'

On Thursday, November 26, 2015, Guillaume Laforge <>

> 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 <
> <javascript:_e(%7B%7D,'cvml','');>> 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 <
>> <javascript:_e(%7B%7D,'cvml','');>>:
>>> 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 <>
> Blog:
> Social: @glaforge <> / Google+
> <>

View raw message