groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: challenges through Java modules (aka jigsaw)
Date Sat, 28 Nov 2015 09:20:24 GMT
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