groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wagenleitner <john.wagenleit...@gmail.com>
Subject Re: progress on executing tests with JDK9 status update
Date Sun, 28 Aug 2016 17:40:52 GMT
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 <blackdrag@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.

Mime
View raw message