Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
Subject: Re: Maven coordinates going forward
To: users@groovy.apache.org
References: <CADQzvmmZ7pqLqqwLQEA6jbDdEbaYKOQkkPE9mgRt4r7owO0S+A@mail.gmail.com>
 <1490860440.23265.6.camel@winder.org.uk>
 <5C676E6359909E478C7B811BDB48CA3567D094@CWWAPP478.windstream.com>
 <CAAJPaVbPTCJTaSaG20Q+SvBN4KLEgk1Z23QBsH6ge5Pw7WKMWA@mail.gmail.com>
 <CAJ2HCd9DA0pPbpMb-D8PmGiZCgVRzwwQgjyJeSo=5WOmfZdwKA@mail.gmail.com>
 <5C676E6359909E478C7B811BDB48CA3567D44F@CWWAPP478.windstream.com>
 <CAMJqDfOMYVhq3jDcLbiPBWerz-z-+BpJuARk4Fa-Wo1ji6Vbjg@mail.gmail.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <58DE2285.1040602@gmx.org>
Date: Fri, 31 Mar 2017 11:33:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CAMJqDfOMYVhq3jDcLbiPBWerz-z-+BpJuARk4Fa-Wo1ji6Vbjg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
archived-at: Fri, 31 Mar 2017 09:34:05 -0000

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