On 30.03.2017 20:58, Miro Bezjak wrote:
[...]
So if we are talking about JDK9 modules them I'm with Jason and the rest
of you. Sure, breaking backwards compatibility is a sensible thing to do
in that case.
and I wish I would know how to solve all the problems. Right now it
seems like Groovy will run in classpath mode better than it will ever as
a module. And I wished we could just stay like that. But once a module
wants to depend on Groovy we are in trouble.
[...]
If my memory serves me right didn't gradle also require groovy1 for
plugin development a long time after release of groovy2 due to fear of
backwards incompatibilities? I believe Jochen calmed their concerns.
I showed them ways to get around the incompatibilities. But yes, groovy1
was required for quite a long time.
And yet again - if the reasons are right - break backwards compatibility.
So now that we have changed the topic, may I ask: is JDK9 modules
compatibility coming in groovy3?
For Groovy in classpath mode there is one more change to do by using
JDK9 specific code, which is to allow to call default methods on proxies.
For Groovy as named module... there are several things to do (writing
down in no order)
* we have to resolve the circular dependency between groovy-test and
groovy-core
* we have duplicated packages in some of our current modules
* we have to decide if we want to go with the same modules at all
* we may have to resort to a fat module that includes everything
* if we want groovy3 and groovy2 as separate modules, they cannot share
exact package names. That has a very big impact on the groovy.lang and
groovy.util package for example.
* if we do no compatibility module for groovy2 (only a jar), then it
means the Groovy 3 module cannot call code from the groovy 2 jar easily.
Not with pure Java at least.
* our joint compilation is untested for modules
* getting gradle to run under JDK9 is quite painful atm. I have yet to
check if using JAVA_OPTS like in
https://github.com/gradle/gradle/issues/719 at the very end will work (I
always tried GRADLE_OPTS and the jvmargs)
* we will have to get accessibility right, which means we have to rework
completely how we build a meta class (and how I planed to build one for
MOP2). This also means we will not be able to call private methods of
Java classes anymore, as the modules system is in the way for this. This
will affect testing and begs the question, if we should do it like we
did in the past for Groovy code still. We actually have this problem in
classpath mode as well. It can be solved by command line switches or by
transforming the modules on load... none of that is a good solution in
my opinion.
* we will have jdk9 specific code and we will require jdk9 for the
build. Thus we will very likely require a multi release jar
* @Grab's usage of the system class loader is no option in JDK9 anymore,
we will have to deprecate things here.
there is most likely a lot more
Also, I like the Céderic's idea of corunnable groovy 2 & 3. Anybody else
entertaining that idea? Is it doable considering the shared groovy.*
packages?
well... depends... if Groovy 3 and 2-compat are in the same module, yes.
Otherwise Groovy 3 has to use a different package. Or we say Groovy 2 is
not available as module and has to be used in classpath mode. Then this
is also possible. to run Groovy 3 and Groovy 2 in classpath mode at the
same time, we still have the problem of overlapping class names in the
same package... GroovyObject for example is very likely to go away,
making most classes in groovy.lang different.
bye Jochen
