groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <fo...@univ-mlv.fr>
Subject Re: challenges through Java modules (aka jigsaw)
Date Thu, 26 Nov 2015 12:58:34 GMT
----- Mail original -----

> De: "Cédric Champeau" <cedric.champeau@gmail.com>
> À: dev@groovy.incubator.apache.org
> 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" < cedric.champeau@gmail.com >
> > 
> 
> > > À: dev@groovy.incubator.apache.org
> > 
> 
> > > 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 < blackdrag@gmx.org > :
> > 
> 

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

Mime
View raw message