----- Mail original ----- > De: "Cédric Champeau" <[email protected]> > À: [email protected] > Envoyé: Jeudi 26 Novembre 2015 13:49:18 > Objet: Re: challenges through Java modules (aka jigsaw)
> > You can have breaking changes in the way the classes are seen from Java > > (and > > jigsaw) without having breaking changes when you use these classes from > > Groovy. > > > By example, you can introduce a way to create type aliases to Groovy, given > > that, you can move Java classes around and keep the same references in the > > Groovy code. > > This would work only if a library is recompiled against the latest Groovy > version (and even more true if you use @CompileStatic), whereas the idea of > backwards compatibility is *not* to recompile everything. That is to say, > take Groovy N+1 and it is capable of running classes compiled with Groovy N. The translation of types can appear at runtime if the type aliases are known by the groovy class loader. I think you only need re-compilation if you use @CompileStatic. > > Also about groovy-all, you can create a module groovy-all that will require > > all other modules, no ? > > Yes, but that's not the purpose of this module today. It's more for guys who > are too lazy to precisely determine all their Groovy module dependencies and > prefer to use groovy-all instead of groovy + "find all modules that I use". > Note that the simplification that I give is recent, because a few releases > ago, groovy-all contained repackaged ASM classes, whereas groovy.jar did > not. Now both have repackaged classes, making it much more consistent and > even less useful to use groovy-all. if it's only packaging, you just have to create a module-info.class that will concatenate all the module-info.class of all other modules, you may need ASM for that :) Rémi > > regards, > > > Rémi > > > > De: "Cédric Champeau" < [email protected] > > > > > > > À: [email protected] > > > > > > Envoyé: Jeudi 26 Novembre 2015 13:10:11 > > > > > > Objet: Re: challenges through Java modules (aka jigsaw) > > > > > > So I'm taking advantage of a bit of free time to write a quick summary of > > > the > > > situation and what we will have to decide. Basically, we have a serious > > > problem (but we will not be the only ones). > > > > > > When you declare a Jigsaw module, one has to declare the list of packages > > > that it exports (and sub-packages are not exported). Those packages are > > > the > > > ones that can be consumed from other Jigsaw modules. It therefore > > > implements > > > strong encapsulation, but making it impossible to reference an internal > > > class of a module, both at compile time and runtime. So far so good. The > > > problem is that the list of packages that belong to a module is exclusive > > > to > > > that module. So if module A exports "foo.bar", another module cannot do > > > the > > > same, or it will fail whenever the 2 modules are loaded at the same time. > > > Worse, *internal packages* are also exclusive, so even if you don't > > > export > > > a > > > package, two modules containing the same internal packages will *also* > > > fail. > > > > > > Why is it a problem for Groovy? It is a problem because we have a very > > > long > > > history. And part of this history makes that modularization was > > > introduced > > > pretty recently, in the 2.0 release. Before, Groovy only had a single > > > module. Now Groovy provides multiple modules, but also a "groovy-all" jar > > > that contains all the classes from all modules. At this point, we can > > > already see that this won't be possible anymore: groovy-all must die, or > > > we > > > must not support modules (sigh). But the problem is even worse. Since the > > > split into modules was done late and that we wanted to preserve backwards > > > compatibility, we decided not to change the packages of classes extracted > > > into their own modules. So for example, XmlParser is found in groovy.util > > > (not groovy.util.xml) in the groovy-xml module, but we also have lots of > > > classes that live into groovy.xml into the "groovy" core module. So in > > > short, our modules are no fit for Jigsaw: we must come back to the very > > > bad > > > state of having everything in a single module. > > > > > > Of course, that's not a satisfactory solution, and of course, there's > > > nothing > > > we can do to influence the decision not to make such a strong > > > requirement: > > > there are technical reasons behind this choice. > > > > > > So what can we do? > > > > > > 1. the easiest, fastest path, is to kill all modules that we have today, > > > and > > > go with a single, good old, groovy-all jar. We would go years backwards, > > > and > > > it's definitely not something we want to do. We want to have *more* > > > modularization, in particular for Android, where the current split is > > > still > > > too big. > > > > > > 2. refactor modules so that each module has its own set of packages, and > > > hope > > > that we don't end up with a big groovy-all jar. Seems very unlikely. > > > > > > 3. break binary compatibility, move classes around, reorganize stuff. > > > > > > Despite my worst nightmare of fragmenting the community (that is what > > > happened for all languages that tried to introduce breaking changes), I > > > think we don't have the choice and we have to go route 3. And if we do > > > so, > > > I > > > would take advantage of this fact to: > > > > > > 1. reorganize our code base even further to separate everything into > > > their > > > own modules and make them as minimal as possible > > > > > > 2. migrate to Java 8 as the minimum JDK version, which would allow us to > > > drop > > > support of the old call site caching, get a new MOP, and possibly > > > removing > > > everything that annoys us in terms of behavior which is kept for the sake > > > of > > > compatibility > > > > > > It's a long road, and it is pretty obvious that we won't be able to be > > > ready > > > for Jigsaw launch (october 2016), but it we don't decide today what we > > > want > > > to do, we will soon be obsolete, because nobody will be able to use > > > Groovy > > > with Jigsaw. > > > > > > Last but not least, as part of the Gradle team, I'd like to take > > > advantage > > > of > > > this to rework our build to make it more consistent, faster, and aimed > > > towards the future. In next January, we will start promoting a smooth > > > migration path to Jigsaw using the Java software model. I think Groovy is > > > still too big to migrate now to the java software model, but at least, we > > > can start investigating. It is crucial to us because Gradle uses Groovy > > > internally, so if Gradle doesn't run on Jigsaw, we will have a medium > > > term > > > problem (medium, because we could still run on JDK 8 but target JDK 9). > > > > > > Let the fun begin! > > > > > > 2015-11-15 17:07 GMT+01:00 Jochen Theodorou < [email protected] > : > > > > > > > On 15.11.2015 12:11, Cédric Champeau wrote: > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > After spending some days at Devoxx, I had a few chats about Jigsaw > > > > > and > > > > > > > > > > > > > > > the implications on Groovy. I will send an email summarizing them and > > > > > I > > > > > > > > > > > > > > > think we need to come up with a plan. > > > > > > > > > > > > > > I was saying that, yes. Seems nobody wanted to believe me > > > > > > > > > > > I'm not sure JIRA is the best way > > > > > > > > > > > > > > > to track this, but in short, we have serious issues coming, and > > > > > breaking > > > > > > > > > > > > > > > changes. Maybe it's a chance for us to make all the breaking changes > > > > > we > > > > > > > > > > > > > > > thought for so long. > > > > > > > > > > > > > > I doubt it, we don't have the manpower, but we can do a bit of course > > > > > > > > > > bye Jochen > > > > > >
