> > > > 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.
> 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. > > 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 >> >> >> > >
