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
