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 Fri, 27 Nov 2015 08:24:11 GMT
2015-11-26 23:58 GMT+01:00 Jeff MAURY <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. Today, all the Groovy classes are exposed. Everything
belongs, de facto, to the public API. Also remember that we have limited
resources. Having to maintain multiple jars + jigsaw + android flavors
while we already have a combination of legacy Groovy + indy Groovy +
android Groovy, it's just going to be a nightmare for Maven users (of
course if you use Gradle it's much easier to substitute one transitive
dependency with another).

My position is that we have so many things to do that it's time to move
forward. I wasn't in that mindset a few weeks ago, but now I think that we
should take advantage that Java 9 is going to break everything in any case.
Also, today, almost nobody use the invokedynamic version because it's too
complicated to activate, because of transitive dependencies (libraries are
built with legacy Groovy, but you want to use the indy version). So let's
simplify everything once for all.


>
> Jeff
>
> On Thu, Nov 26, 2015 at 10:45 PM, Jesper Steen Møller <
> jesper@selskabet.org> wrote:
>
>> Hi list
>>
>> If it’s primarily a question of moving files in modules out into distinct
>> package names, how about doing the following:
>> 1) Move to a Jigsaw-compatible module split going forward, thus breaking
>> compatibility for Jigsaw adopters, and
>> 2) Provide a “compatibility” overlay jar containing all the classes with
>> old package names for non-jigsaw users?
>>
>> That way, only people targetting Jigsaw-enabled runtimes will be hit by
>> the source imcompatibility.
>>
>> -Jesper
>>
>> > On 26. nov. 2015, at 21.29, Jochen Theodorou <blackdrag@gmx.org> wrote:
>> >
>> > On 26.11.2015 21:05, Guillaume Laforge wrote:
>> >> 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.
>> >
>> > I think we need a list of the specific cases, then we can talk about
>> the seize of the impact.
>> >
>> > You two know I was all for a big change (MOP2). I am worried about the
>> manpower to actually do that change. I was back then already actually and
>> did not want to do it all alone.
>> >
>> > If a source converter can be done the barrier sure is smaller. On the
>> other hand Python had https://docs.python.org/2/library/2to3.html
>> >
>> > bye blackdrag
>>
>>
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com
> http://www.twitter.com/jeffmaury
>

Mime
View raw message