Groovy+Java9 status?

[Robert Scholte <rf...@apache.org>]

Hi,

for Apache Maven I've started to create Jenkins jobs to verify if our  
(sub)projects can be built with JDK9/Jigsaw.
For the integration tests of our maven plugins we often use the  
maven-invoker-plugin, which has the option to run a preBuildHookScript and  
postBuildHookScript to put the plugin in a certain state and to verify the  
results. The plugin supports Groovy and BeanShell out of the box.

I know for Groovy to support Java9 is a real challenge. We should be able  
to help confirming that all still works well with Java9.

Concrete I see issues like below and can't find any references in Jira:
e.g. with groovy-all-2.4.7 I get the following exception:

[INFO] Building: reportConfig\pom.xml
[INFO] run script verify.groovy
[INFO] ..FAILED (9.4 s)
[INFO]   The post-build script did not succeed. No signature of method:  
java.io.File.exists() is applicable for argument types: () values: []
Possible solutions: print(java.lang.Object), write(java.lang.String),  
print(java.io.PrintWriter), with(groovy.lang.Closure),  
is(java.lang.Object), printf(java.lang.String, [Ljava.lang.Object;)

I can see what the issue is (Groovy's File versus JRE File), and I'm  
wondering what to expect: will this be fixed in Groovy, or do we have to  
rewrite a huge amount of scripts? I really hope the first.

thanks,
Robert

https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw

Re: Groovy+Java9 status?

[Sven Reimers <sv...@gmail.com>]

Any idea on the roadmap for 2.4.8 release?

Thanks

Sven

Am 03.12.2016 11:52 schrieb "Jochen Theodorou" <bl...@gmx.org>:

> On 02.12.2016 17:55, Robert Scholte wrote:
> [...]
>
>> Concrete I see issues like below and can't find any references in Jira:
>> e.g. with groovy-all-2.4.7 I get the following exception:
>>
>> [INFO] Building: reportConfig\pom.xml
>> [INFO] run script verify.groovy
>> [INFO] ..FAILED (9.4 s)
>> [INFO]   The post-build script did not succeed. No signature of method:
>> java.io.File.exists() is applicable for argument types: () values: []
>> Possible solutions: print(java.lang.Object), write(java.lang.String),
>> print(java.io.PrintWriter), with(groovy.lang.Closure),
>> is(java.lang.Object), printf(java.lang.String, [Ljava.lang.Object;)
>>
>
> 2.4.8 will have a fix for that.
>
> I can see what the issue is (Groovy's File versus JRE File), and I'm
>> wondering what to expect: will this be fixed in Groovy, or do we have to
>> rewrite a huge amount of scripts? I really hope the first.
>>
>
> Groovy's File is the JRE File. The problem is that with
> #AwkwardStrongEncapsulation they decided an exported class can have private
> method for which setAccessible won´t ever work. So the strategy Groovy
> used, which is using setAccessible(true) on the array of Method (gotten by
> reflection) cannot work anymore, which means we now have to do that an a
> per method base and blend-out those, we cannot gain access to using
> setAccessible. The fix for this is there and in the repository. All that is
> missing is a release.
>
> bye Jochen
>
>

Re: Groovy+Java9 status?

[Robert Scholte <rf...@apache.org>]

On Sat, 03 Dec 2016 11:52:49 +0100, Jochen Theodorou <bl...@gmx.org>  
wrote:

> On 02.12.2016 17:55, Robert Scholte wrote:
> [...]
>> Concrete I see issues like below and can't find any references in Jira:
>> e.g. with groovy-all-2.4.7 I get the following exception:
>>
>> [INFO] Building: reportConfig\pom.xml
>> [INFO] run script verify.groovy
>> [INFO] ..FAILED (9.4 s)
>> [INFO]   The post-build script did not succeed. No signature of method:
>> java.io.File.exists() is applicable for argument types: () values: []
>> Possible solutions: print(java.lang.Object), write(java.lang.String),
>> print(java.io.PrintWriter), with(groovy.lang.Closure),
>> is(java.lang.Object), printf(java.lang.String, [Ljava.lang.Object;)
>
> 2.4.8 will have a fix for that.

That's great news. I've just tested the project with 2.4.8-SNAPSHOT and  
can confirm this fixes our issue.

thanks,
Robert

>
>> I can see what the issue is (Groovy's File versus JRE File), and I'm
>> wondering what to expect: will this be fixed in Groovy, or do we have to
>> rewrite a huge amount of scripts? I really hope the first.
>
> Groovy's File is the JRE File. The problem is that with  
> #AwkwardStrongEncapsulation they decided an exported class can have  
> private method for which setAccessible won´t ever work. So the strategy  
> Groovy used, which is using setAccessible(true) on the array of Method  
> (gotten by reflection) cannot work anymore, which means we now have to  
> do that an a per method base and blend-out those, we cannot gain access  
> to using setAccessible. The fix for this is there and in the repository.  
> All that is missing is a release.
>
> bye Jochen

Re: Groovy+Java9 status?

[Jochen Theodorou <bl...@gmx.org>]

On 02.12.2016 17:55, Robert Scholte wrote:
[...]
> Concrete I see issues like below and can't find any references in Jira:
> e.g. with groovy-all-2.4.7 I get the following exception:
>
> [INFO] Building: reportConfig\pom.xml
> [INFO] run script verify.groovy
> [INFO] ..FAILED (9.4 s)
> [INFO]   The post-build script did not succeed. No signature of method:
> java.io.File.exists() is applicable for argument types: () values: []
> Possible solutions: print(java.lang.Object), write(java.lang.String),
> print(java.io.PrintWriter), with(groovy.lang.Closure),
> is(java.lang.Object), printf(java.lang.String, [Ljava.lang.Object;)

2.4.8 will have a fix for that.

> I can see what the issue is (Groovy's File versus JRE File), and I'm
> wondering what to expect: will this be fixed in Groovy, or do we have to
> rewrite a huge amount of scripts? I really hope the first.

Groovy's File is the JRE File. The problem is that with 
#AwkwardStrongEncapsulation they decided an exported class can have 
private method for which setAccessible won�t ever work. So the strategy 
Groovy used, which is using setAccessible(true) on the array of Method 
(gotten by reflection) cannot work anymore, which means we now have to 
do that an a per method base and blend-out those, we cannot gain access 
to using setAccessible. The fix for this is there and in the repository. 
All that is missing is a release.

bye Jochen