Re: progress on executing tests with JDK9 status update

[Thibault Kruse]

In that case sorry for the misinformation. Sorry I won't have time to look
at the last failing test.

On Thursday, September 8, 2016, John Wagenleitner <
john.wagenleit...@gmail.com> wrote:

> On Wed, Sep 7, 2016 at 11:55 AM, Jochen Theodorou  > wrote:
>
>> On 07.09.2016 19:54, John Wagenleitner wrote:
>>
>>> On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou >> 
>>> >> >> wrote:
>>>
>>>
>>>
>>> On 07.09.2016 14:33, Thibault Kruse wrote:
>>>
>>> The groovysh tests failed last because the strategy to read
>>> package
>>> contents via the ClassLoader does not work with Java8. Possibly
>>> checking how the new Java REPL does things could reveal a
>>> solution, if
>>> they do have tab completion for imports. In the meantime, I'd
>>> suggest
>>> skipping those tests when testing with Java9. Not having
>>> completion
>>> for imports in groovysh with Java9 should probably not be
>>> critical.
>>>
>>>
>>> How about basing this on the classpath property instead? That is
>>> what I did for 90% of the other failing tests
>>>
>>>
>>>
>>> All of the groovysh tests pass for me using build 9-ea+134-jigsaw.
>>>
>>
>>
>> really? that would be strange since I did see getResource calls to find
>> .class files and it was said, that this is not supported anymore in
>> JDK9/jigsaw and then again, I can confirm that everything works with
>> ea+134-jigsaw. Strange. I also tested the indy version of the build, and
>> everything seems to work fine.
>>
>> Nice!
>>
>> bye Jochen
>>
>>
>>
>>
>
> There was special jigsaw handling added [1].  For a span of builds it
> wasn't working but as of the recent builds I think some fixes to the jrt
> filesystem were fixed so now it passes.  After the recent changes now there
> is just one failing Swing test.
>
> [1] https://github.com/apache/groovy/blob/d1fdc38c2c2c0539b434326b37b813
> 328ced96a4/subprojects/groovy-groovysh/src/main/groovy/org/
> codehaus/groovy/tools/shell/util/PackageHelperImpl.groovy#L118-L122
>

Re: progress on executing tests with JDK9 status update

[John Wagenleitner]

On Wed, Sep 7, 2016 at 11:55 AM, Jochen Theodorou  wrote:

> On 07.09.2016 19:54, John Wagenleitner wrote:
>
>> On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou > > wrote:
>>
>>
>>
>> On 07.09.2016 14:33, Thibault Kruse wrote:
>>
>> The groovysh tests failed last because the strategy to read
>> package
>> contents via the ClassLoader does not work with Java8. Possibly
>> checking how the new Java REPL does things could reveal a
>> solution, if
>> they do have tab completion for imports. In the meantime, I'd
>> suggest
>> skipping those tests when testing with Java9. Not having
>> completion
>> for imports in groovysh with Java9 should probably not be
>> critical.
>>
>>
>> How about basing this on the classpath property instead? That is
>> what I did for 90% of the other failing tests
>>
>>
>>
>> All of the groovysh tests pass for me using build 9-ea+134-jigsaw.
>>
>
>
> really? that would be strange since I did see getResource calls to find
> .class files and it was said, that this is not supported anymore in
> JDK9/jigsaw and then again, I can confirm that everything works with
> ea+134-jigsaw. Strange. I also tested the indy version of the build, and
> everything seems to work fine.
>
> Nice!
>
> bye Jochen
>
>
>
>

There was special jigsaw handling added [1].  For a span of builds it
wasn't working but as of the recent builds I think some fixes to the jrt
filesystem were fixed so now it passes.  After the recent changes now there
is just one failing Swing test.

[1]
https://github.com/apache/groovy/blob/d1fdc38c2c2c0539b434326b37b813328ced96a4/subprojects/groovy-groovysh/src/main/groovy/org/codehaus/groovy/tools/shell/util/PackageHelperImpl.groovy#L118-L122

Re: progress on executing tests with JDK9 status update

[Jochen Theodorou]

On 07.09.2016 19:54, John Wagenleitner wrote:

On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou mailto:blackd...@gmx.org>> wrote:



On 07.09.2016 14:33, Thibault Kruse wrote:

The groovysh tests failed last because the strategy to read package
contents via the ClassLoader does not work with Java8. Possibly
checking how the new Java REPL does things could reveal a
solution, if
they do have tab completion for imports. In the meantime, I'd
suggest
skipping those tests when testing with Java9. Not having completion
for imports in groovysh with Java9 should probably not be critical.


How about basing this on the classpath property instead? That is
what I did for 90% of the other failing tests



All of the groovysh tests pass for me using build 9-ea+134-jigsaw.



really? that would be strange since I did see getResource calls to find 
.class files and it was said, that this is not supported anymore in 
JDK9/jigsaw and then again, I can confirm that everything works with 
ea+134-jigsaw. Strange. I also tested the indy version of the build, and 
everything seems to work fine.


Nice!

bye Jochen

Re: progress on executing tests with JDK9 status update

[John Wagenleitner]

On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou  wrote:

>
>
> On 07.09.2016 14:33, Thibault Kruse wrote:
>
>> The groovysh tests failed last because the strategy to read package
>> contents via the ClassLoader does not work with Java8. Possibly
>> checking how the new Java REPL does things could reveal a solution, if
>> they do have tab completion for imports. In the meantime, I'd suggest
>> skipping those tests when testing with Java9. Not having completion
>> for imports in groovysh with Java9 should probably not be critical.
>>
>
> How about basing this on the classpath property instead? That is what I
> did for 90% of the other failing tests
>
>

All of the groovysh tests pass for me using build 9-ea+134-jigsaw.

Re: progress on executing tests with JDK9 status update

[Jochen Theodorou]

On 07.09.2016 14:33, Thibault Kruse wrote:

The groovysh tests failed last because the strategy to read package
contents via the ClassLoader does not work with Java8. Possibly
checking how the new Java REPL does things could reveal a solution, if
they do have tab completion for imports. In the meantime, I'd suggest
skipping those tests when testing with Java9. Not having completion
for imports in groovysh with Java9 should probably not be critical.


How about basing this on the classpath property instead? That is what I 
did for 90% of the other failing tests


bye Jochen

Re: progress on executing tests with JDK9 status update

[Thibault Kruse]

The groovysh tests failed last because the strategy to read package
contents via the ClassLoader does not work with Java8. Possibly
checking how the new Java REPL does things could reveal a solution, if
they do have tab completion for imports. In the meantime, I'd suggest
skipping those tests when testing with Java9. Not having completion
for imports in groovysh with Java9 should probably not be critical.

On Wed, Sep 7, 2016 at 6:23 AM, Jochen Theodorou  wrote:
> Another update on JDK9...
>
> I now managed to make the last groovy-core tests running! I used jigsaw-132
> for the test.
>
> Doing a full Groovy build, the only part missing now is the tests in
> groovysh. There org.codehaus.groovy.tools.shell.util.PackageHelperImplTest
> multiple times and I have not yet investigated why. I also did not test the
> indy version of the build yet.
>
> bye Jochen
>
>

Re: progress on executing tests with JDK9 status update

[Guillaume Laforge]

Great progress!

Le mardi 6 septembre 2016, Jochen Theodorou  a écrit :

> Another update on JDK9...
>
> I now managed to make the last groovy-core tests running! I used
> jigsaw-132 for the test.
>
> Doing a full Groovy build, the only part missing now is the tests in
> groovysh. There org.codehaus.groovy.tools.shell.util.PackageHelperImplTest
> multiple times and I have not yet investigated why. I also did not test the
> indy version of the build yet.
>
> bye Jochen
>
>
>

-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+

Re: progress on executing tests with JDK9 status update

[Jochen Theodorou]

Another update on JDK9...

I now managed to make the last groovy-core tests running! I used 
jigsaw-132 for the test.


Doing a full Groovy build, the only part missing now is the tests in 
groovysh. There 
org.codehaus.groovy.tools.shell.util.PackageHelperImplTest multiple 
times and I have not yet investigated why. I also did not test the indy 
version of the build yet.


bye Jochen

Re: progress on executing tests with JDK9 status update

[John Wagenleitner]

On Thu, Aug 25, 2016 at 7:57 AM, John Wagenleitner <
john.wagenleit...@gmail.com> wrote:

>
> On Wed, Aug 24, 2016 at 10:29 PM, Jochen Theodorou 
> wrote:
>
>> On 25.08.2016 01:14, John Wagenleitner wrote:
>> [...]
>>
>>> groovy.transform.stc.GenericsSTCTest > testGenericField FAILED
>>> org.codehaus.groovy.control.Mu
>>> ltipleCompilationErro
>>> rsException:
>>> startup failed:
>>>  TestScripttestGenericField257.groovy: 2: unable to resolve
>>> class javax.xml.ws.Holder
>>>   @ line 2, column 13.
>>> import javax.xml.ws.Holder
>>> ^
>>>
>>>
>>> there are 2 of this kind of failure. The problem being that you need
>>> access to the module java.xml.ws  or java.se.ee
>>>  to be able to get Holder class. I did not manage
>>> to solve this one yet. "org.gradle.jvmargs=-ea -Xmx1G -addmods
>>> java.se.ee " did not fix the failure. Makes me
>>> wonder if that is then also used for tests.
>>>
>>> I had looked at that and I don't think the
>>> GenericsSTCTest.testGenericField needs to rely on the java.xml.ws.Holder
>>> class in order to be an effective test.  I think it could be replaced by
>>> class defined inline in the assertScript and then the dependency on the
>>> java.xml module can be eliminated for core tests.
>>>
>>
>> yes, but
>> (a) what would be a good replacement? It should be nothing like a
>> collection. And it should be in java7
>>
>
>
> I think the following would work as a replacement assert for that test.
> This fails on 2.1.3 (as specified in GROOVY-6135) and works on versions
> since as does the current assert using javax.xml.ws.Holder.
>
> assertScript '''
> class MyClass {
> static void main(args) {
> Holder holder = new Holder()
> holder.value = 5
> assert holder.value > 4
> }
> private static class Holder {
> T value
> }
> }
> '''
>
>
>> (b) won´t we get the same problem with groovy-xml later on?
>>
>>
>
> I think we've already hit this problem in groovy-xml (and it's dependent
> projects like templates) and think that the new jdk9.gradle addresses it.
> Unless necessary, it might be nice to keep core depending only on what's
> available in the java.se module.
>


I updated the test to remove the dependence on javax.xml.

The jigsaw version on the TC server is build 123 which is pretty old, with
newer builds some of the failing shell tests pass.  Would probably be good
to update to the latest build if possible.

Re: progress on executing tests with JDK9 status update

[John Wagenleitner]

On Wed, Aug 24, 2016 at 10:29 PM, Jochen Theodorou 
wrote:

> On 25.08.2016 01:14, John Wagenleitner wrote:
> [...]
>
>> groovy.transform.stc.GenericsSTCTest > testGenericField FAILED
>> org.codehaus.groovy.control.Mu
>> ltipleCompilationErro
>> rsException:
>> startup failed:
>>  TestScripttestGenericField257.groovy: 2: unable to resolve
>> class javax.xml.ws.Holder
>>   @ line 2, column 13.
>> import javax.xml.ws.Holder
>> ^
>>
>>
>> there are 2 of this kind of failure. The problem being that you need
>> access to the module java.xml.ws  or java.se.ee
>>  to be able to get Holder class. I did not manage
>> to solve this one yet. "org.gradle.jvmargs=-ea -Xmx1G -addmods
>> java.se.ee " did not fix the failure. Makes me
>> wonder if that is then also used for tests.
>>
>> I had looked at that and I don't think the
>> GenericsSTCTest.testGenericField needs to rely on the java.xml.ws.Holder
>> class in order to be an effective test.  I think it could be replaced by
>> class defined inline in the assertScript and then the dependency on the
>> java.xml module can be eliminated for core tests.
>>
>
> yes, but
> (a) what would be a good replacement? It should be nothing like a
> collection. And it should be in java7
>


I think the following would work as a replacement assert for that test.
This fails on 2.1.3 (as specified in GROOVY-6135) and works on versions
since as does the current assert using javax.xml.ws.Holder.

assertScript '''
class MyClass {
static void main(args) {
Holder holder = new Holder()
holder.value = 5
assert holder.value > 4
}
private static class Holder {
T value
}
}
'''


> (b) won´t we get the same problem with groovy-xml later on?
>
>

I think we've already hit this problem in groovy-xml (and it's dependent
projects like templates) and think that the new jdk9.gradle addresses it.
Unless necessary, it might be nice to keep core depending only on what's
available in the java.se module.

Re: progress on executing tests with JDK9 status update

[Jochen Theodorou]

On 25.08.2016 01:14, John Wagenleitner wrote:
[...]

groovy.transform.stc.GenericsSTCTest > testGenericField FAILED
org.codehaus.groovy.control.Mu
ltipleCompilationErrorsException:
startup failed:
 TestScripttestGenericField257.groovy: 2: unable to resolve
class javax.xml.ws.Holder
  @ line 2, column 13.
import javax.xml.ws.Holder
^


there are 2 of this kind of failure. The problem being that you need
access to the module java.xml.ws  or java.se.ee
 to be able to get Holder class. I did not manage
to solve this one yet. "org.gradle.jvmargs=-ea -Xmx1G -addmods
java.se.ee " did not fix the failure. Makes me
wonder if that is then also used for tests.

I had looked at that and I don't think the
GenericsSTCTest.testGenericField needs to rely on the java.xml.ws.Holder
class in order to be an effective test.  I think it could be replaced by
class defined inline in the assertScript and then the dependency on the
java.xml module can be eliminated for core tests.


yes, but
(a) what would be a good replacement? It should be nothing like a 
collection. And it should be in java7

(b) won´t we get the same problem with groovy-xml later on?

bye Jochen

Re: progress on executing tests with JDK9 status update

[John Wagenleitner]

On Wed, Aug 24, 2016 at 2:32 PM, Jochen Theodorou  wrote:

> Hi all,
>
> I made two more tests pass with JDK9 and we are now down to 8 failures in
> groovy-core.
>
> gls.innerClass.InnerClassTest > testThisReferenceForAICInOpenBlock FAILED
>> groovy.lang.MissingMethodException: No signature of method:
>> java.lang.reflect.Field.isAccessible() is applicable for argument types:
>> () values: []
>> Possible solutions: setAccessible(boolean)
>>
>
> is something I have yet to investigate
>
> groovy.transform.stc.STCExtensionMethodsTest >
>> testShouldFindExtensionMethodWithGrab FAILED
>> java.lang.RuntimeException: Unable to find class loader
>>
>
> this is similar to about 4 more failures... for which I have no solution
> independent of jdk9 really. So I guess a jdk9 specific solution will have
> to be done.
>
> groovy.transform.stc.GenericsSTCTest > testGenericField FAILED
>> org.codehaus.groovy.control.MultipleCompilationErrorsException:
>> startup failed:
>> TestScripttestGenericField257.groovy: 2: unable to resolve class
>> javax.xml.ws.Holder
>>  @ line 2, column 13.
>>import javax.xml.ws.Holder
>>^
>>
>
> there are 2 of this kind of failure. The problem being that you need
> access to the module java.xml.ws or java.se.ee to be able to get Holder
> class. I did not manage to solve this one yet. "org.gradle.jvmargs=-ea
> -Xmx1G -addmods java.se.ee" did not fix the failure. Makes me wonder if
> that is then also used for tests.
>


I had looked at that and I don't think the GenericsSTCTest.testGenericField
needs to rely on the java.xml.ws.Holder class in order to be an effective
test.  I think it could be replaced by class defined inline in the
assertScript and then the dependency on the java.xml module can be
eliminated for core tests.

progress on executing tests with JDK9 status update

[Jochen Theodorou]

Hi all,

I made two more tests pass with JDK9 and we are now down to 8 failures 
in groovy-core.



gls.innerClass.InnerClassTest > testThisReferenceForAICInOpenBlock FAILED
groovy.lang.MissingMethodException: No signature of method: 
java.lang.reflect.Field.isAccessible() is applicable for argument types: () 
values: []
Possible solutions: setAccessible(boolean)


is something I have yet to investigate


groovy.transform.stc.STCExtensionMethodsTest > 
testShouldFindExtensionMethodWithGrab FAILED
java.lang.RuntimeException: Unable to find class loader


this is similar to about 4 more failures... for which I have no solution 
independent of jdk9 really. So I guess a jdk9 specific solution will 
have to be done.



groovy.transform.stc.GenericsSTCTest > testGenericField FAILED
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup 
failed:
TestScripttestGenericField257.groovy: 2: unable to resolve class 
javax.xml.ws.Holder
 @ line 2, column 13.
   import javax.xml.ws.Holder
   ^


there are 2 of this kind of failure. The problem being that you need 
access to the module java.xml.ws or java.se.ee to be able to get Holder 
class. I did not manage to solve this one yet. "org.gradle.jvmargs=-ea 
-Xmx1G -addmods java.se.ee" did not fix the failure. Makes me wonder if 
that is then also used for tests.


bye Jochen