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 <[email protected]> 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
