progress on executing tests with JDK9 status update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: progress on executing tests with JDK9 status update

jwagenleitner

On Wed, Aug 24, 2016 at 2:32 PM, Jochen Theodorou <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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
>         <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
Reply | Threaded
Open this post in threaded view
|

Re: progress on executing tests with JDK9 status update

jwagenleitner

On Wed, Aug 24, 2016 at 10:29 PM, Jochen Theodorou <[hidden email]> wrote:
On <a href="tel:25.08.2016%2001" value="+12508201601" target="_blank">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
 

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.
Reply | Threaded
Open this post in threaded view
|

Re: progress on executing tests with JDK9 status update

jwagenleitner
On Thu, Aug 25, 2016 at 7:57 AM, John Wagenleitner <[hidden email]> wrote:

On Wed, Aug 24, 2016 at 10:29 PM, Jochen Theodorou <[hidden email]> wrote:
On <a href="tel:25.08.2016%2001" value="+12508201601" target="_blank">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
 

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.
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Re: progress on executing tests with JDK9 status update

Guillaume Laforge
Administrator
Great progress!

Le mardi 6 septembre 2016, Jochen Theodorou <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: progress on executing tests with JDK9 status update

Thibault Kruse
In reply to this post by Jochen Theodorou
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 <[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: progress on executing tests with JDK9 status update

jwagenleitner
On Wed, Sep 7, 2016 at 8:50 AM, Jochen Theodorou <[hidden email]> 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.
12