You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Jochen Theodorou <bl...@gmx.org> on 2016/08/24 21:32:29 UTC
progress on executing tests with JDK9 status update
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
Re: progress on executing tests with JDK9 status update
Posted by Guillaume Laforge <gl...@gmail.com>.
Great progress!
Le mardi 6 septembre 2016, Jochen Theodorou <bl...@gmx.org> 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 <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: progress on executing tests with JDK9 status update
Posted by Thibault Kruse <ti...@googlemail.com>.
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.wagenleitner@gmail.com> wrote:
> On Wed, Sep 7, 2016 at 11:55 AM, Jochen Theodorou <blackdrag@gmx.org
> <javascript:_e(%7B%7D,'cvml','blackdrag@gmx.org');>> wrote:
>
>> On 07.09.2016 19:54, John Wagenleitner wrote:
>>
>>> On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou <blackdrag@gmx.org
>>> <javascript:_e(%7B%7D,'cvml','blackdrag@gmx.org');>
>>> <mailto:blackdrag@gmx.org
>>> <javascript:_e(%7B%7D,'cvml','blackdrag@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
>>
>>
>>
>>
>
> 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
Posted by John Wagenleitner <jo...@gmail.com>.
On Wed, Sep 7, 2016 at 11:55 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> On 07.09.2016 19:54, John Wagenleitner wrote:
>
>> On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou <blackdrag@gmx.org
>> <ma...@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
>
>
>
>
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
Posted by Jochen Theodorou <bl...@gmx.org>.
On 07.09.2016 19:54, John Wagenleitner wrote:
> On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou <blackdrag@gmx.org
> <ma...@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
Posted by John Wagenleitner <jo...@gmail.com>.
On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou <bl...@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.
Re: progress on executing tests with JDK9 status update
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Posted by Thibault Kruse <ti...@googlemail.com>.
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 <bl...@gmx.org> 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
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Posted by John Wagenleitner <jo...@gmail.com>.
On Thu, Aug 25, 2016 at 7:57 AM, John Wagenleitner <
john.wagenleitner@gmail.com> wrote:
>
> On Wed, Aug 24, 2016 at 10:29 PM, Jochen Theodorou <bl...@gmx.org>
> wrote:
>
>> On 25.08.2016 01:14, John Wagenleitner wrote:
>> [...]
>>
>>> groovy.transform.stc.GenericsSTCTest > testGenericField FAILED
>>> org.codehaus.groovy.control.Mu
>>> <http://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 <http://java.xml.ws> or java.se.ee
>>> <http://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 <http://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<Integer> holder = new Holder<Integer>()
> holder.value = 5
> assert holder.value > 4
> }
> private static class Holder<T> {
> 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
Posted by John Wagenleitner <jo...@gmail.com>.
On Wed, Aug 24, 2016 at 10:29 PM, Jochen Theodorou <bl...@gmx.org>
wrote:
> On 25.08.2016 01:14, John Wagenleitner wrote:
> [...]
>
>> groovy.transform.stc.GenericsSTCTest > testGenericField FAILED
>> org.codehaus.groovy.control.Mu
>> <http://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 <http://java.xml.ws> or java.se.ee
>> <http://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 <http://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<Integer> holder = new Holder<Integer>()
holder.value = 5
assert holder.value > 4
}
private static class Holder<T> {
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
Posted by Jochen Theodorou <bl...@gmx.org>.
On 25.08.2016 01:14, John Wagenleitner wrote:
[...]
> groovy.transform.stc.GenericsSTCTest > testGenericField FAILED
> org.codehaus.groovy.control.Mu
> <http://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 <http://java.xml.ws> or java.se.ee
> <http://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 <http://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
Posted by John Wagenleitner <jo...@gmail.com>.
On Wed, Aug 24, 2016 at 2:32 PM, Jochen Theodorou <bl...@gmx.org> 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.