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 Sat, 28 Nov 2015 09:25:46 GMT
Modules can export internals to Groovy, thanks to the concept of "automatic
modules". However, the automatic modules are inferred from the jar name.
Which is a weak strategy, but honestly I can't find any better solution. So
for groovy, since we have multiple flavors, this is a problem. Because we
have groovy-all, groovy, and all individual modules. That's just a
nightmare.

BTW, I recommend that everybody interested in this topic takes an hour to
see this talk from Mark Reinholds:
https://www.youtube.com/watch?v=UKC0uC7QUkI

2015-11-28 10:20 GMT+01:00 Jochen Theodorou <blackdrag@gmx.org>:

> On 27.11.2015 09:24, Cédric Champeau wrote:
>
>>
>>
>> 2015-11-26 23:58 GMT+01:00 Jeff MAURY <jeffmaury@jeffmaury.com
>> <mailto:jeffmaury@jeffmaury.com>>:
>>
>>     +1 for Jesper proposition with the modification that 2 being
>>     groovy-all.jar with binary compatibility but also a Jigsaw module.
>>     So we could have:
>>     Groovy 3.x: several Jigsaw module refactored
>>     Groovy 2.x: same packaging with groovy-all being a stand alone
>>     Jigsaw module.
>>
>>
>> I think that's more or less strictly equivalent to the current
>> situation: Groovy 2 "groovy-all" being a jigsaw module can be as simple
>> as exporting all packages. And we don't even have to: just put the jar
>> on classpath and it's done. The problem comes as soon as we want to
>> restrict some things to internal packages.
>>
>
> That's not fully right. Being on the classpath only means we will then be
> in the unnamed module. Other modules have then no way of exporting their
> internals to groovy (well, I think there are ways at runtime, but I am not
> sure). Which means groovy cannot call methods in those packages, which
> means those modules cannot be written in Groovy... at least that is how I
> do understand things.
>
> Today, all the Groovy classes
>> are exposed. Everything belongs, de facto, to the public API.
>>
>
> Well, we did not even really try to prevent this in the past. The mess
> could have been lowered with a more restrictive package named based
> convention.
>
>
> bye blackdrag
>

Mime
View raw message