groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: challenges through Java modules (aka jigsaw)
Date Thu, 26 Nov 2015 13:16:32 GMT
On 26.11.2015 13:10, C├ędric Champeau wrote:
> 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.

Examples of these fails (copied from a mail to the jigsaw list I did):

* groovy-console has a conflict in groovy.ui
* groovy-ant has a conflict in groovy.util
* groovy-docgenerator in org.codehaus.groovy.tools
* groovy-nio in org.codehaus.groovy.runtime
* groovy-sql in org.codehaus.groovy.runtime
* groovy-swing in org.codehaus.groovy.runtime
* groovy-test in goovy.lang and groovy.util
* groovy-xml in org.codehaus.groovy.runtime and goovy.util

The imho biggest problem is GroovyTestCase being in groovy-test, but 
also in groovy.util

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

I was mentioning the split of runtime and compiler on the jigsaw list. 
The suggestion was basically to make a service provider based logic... 
But frankly, the android version does not have to use modules at all, 
does it?

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

I think the conflicts in org.codehaus.groovy.runtime can be solved. 
groovy.util and groovy.lang conflicts are the really problematic ones... 
and just giving them their own packages won't prevent way (3). A variant 
of (2) is to deprecate all non-solvable conflicting modules and provide 
alternatives. That would hit mostly groovy-test and groovy-xml, and 
maybe require a conceptual change... we could for example go more the 
junit4 route and not require extending GroovyTestCase anymore, but 
instead have an annotation.. which then would of course not be in 
groovy.util or groovy.lang. Still a huge change of course.

> 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

We will have to think of milestones for this.... and probably many of them

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

Not entirely right imho. You can then still use Groovy, but not as a 
real module and probably only groovy-all and with nothing written in 
Groovy as module. That will of course not help Gradle or Grails.

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

I think a new MOP is out of scope for this. As much as I would like to 
have a better MOP, which for a change can be really specified in a 
document and is not as overly complex as the current one, we have to be 
realistic. And a really new MOP (not one simply tweaked a bit and still 
breaking lot's of things) requires imho more than a man year to 
implement and migrate the codebase. I don't see that kind of resources 
available without more than one fulltime developer. And we don't have 
even one. I summed up some ideas for a slower migration path to a new 
MOP in 
http://blackdragsview.blogspot.ch/2015/03/thoughts-about-new-meta-class-system.html 
But well... only some ideas.

I think we should concentrate on solving the package name conflicts in 
the new module system first... which basically is route 2. I am pretty 
sure the jdk9 problems won't end there and we need time to solve these 
problems as well... Of course we could still think about getting rid of 
the callsite caching part and depend on say JDK7 as minimum version.

bye blackdrag



Mime
View raw message