Mailing-List: contact dev-help@groovy.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.incubator.apache.org
Subject: Re: challenges through Java modules (aka jigsaw)
To: dev@groovy.incubator.apache.org
References: <56164EAB.1030302@gmx.org>
 <CAByu6UVLBaJ9Ad8eMqPt2knbn4UTpeDkWGm0bxY+yVwx3SW-HQ@mail.gmail.com>
 <CADQzvmkPunNym4Xra7xn8nvrwghhUgP7Ah06=CwW+e+AZ+MS7w@mail.gmail.com>
 <5648ADB3.9090906@gmx.org>
 <CADQzvm=LX9LXQEoObhEfV-NkaP-c-Dnkw-0B7d2W3-4zKtgbnw@mail.gmail.com>
 <56570630.4060401@gmx.org> <56574CFC.4030204@gmx.net>
 <CADQzvmkiS05=yoFbpcRbeJVPHFOfpgcFvW7sFLOoNMME0WMw4w@mail.gmail.com>
 <CAJ2HCd-UbJyuuPqr_MCpFCgD6e665p2GGTasUVu-nn44TFzj5A@mail.gmail.com>
 <56576B9E.3040601@gmx.org>
 <C448EAF7-1B4E-4E8E-B7CE-A61BB25DF3E3@selskabet.org>
 <CANyrOm7pkagY_mxBswbp6HD6FXocrgrix7X1VRaa1FMg9uDu8Q@mail.gmail.com>
 <CADQzvmkigw=J+GQR1Ah1UKZRUqgtsgQbW3huMU89=6xyFN1SGA@mail.gmail.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <565971D8.4050502@gmx.org>
Date: Sat, 28 Nov 2015 10:20:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
 <CADQzvmkigw=J+GQR1Ah1UKZRUqgtsgQbW3huMU89=6xyFN1SGA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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