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 19:49:36 GMT
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 <pascalschumacher@gmx.net>:

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

Mime
View raw message