Groovy 5 support

[matrei]

Hi everyone, thanks for this amazing framework!
I have been enjoying using it since forever, mainly in Grails projects.

Groovy 5 is about stabilize and start releasing beta versions.
I am in the process of setting up a CI workflow in the Grails Core repository to test Groovy 5 compatibility.

One thing that popped out was that the Spock thrown method does not work with Groovy 5:

void 'Test promise timeout handling'() {
        
    when: 'a promise that takes longer than the timeout'
        def p = Promises.createPromise {
            sleep 1000
            println 'completed op'
        }
        p.get(50, TimeUnit.MILLISECONDS)

    then: 'a timeout error occurs'
        thrown TimeoutException
}

GparsPromiseSpec > Test promise timeout handling FAILED
    groovy.lang.MissingMethodException: No signature of method: grails.async.GparsPromiseSpec.thrownImpl() is applicable for argument types: (null, null, Class) values: [null, null, class java.util.concurrent.TimeoutException]
    Possible solutions: thrown()
        at grails.async.GparsPromiseSpec.Test promise timeout handling(GparsPromiseSpec.groovy:61)

Are there any discussions or work going on towards supporting Groovy 5?
(I'd be happy to pitch in, in any way I can, if help is needed.)

[Vampire]

Seems at least with Groovy 5.0.0-alpha-8 it works fine: https://groovyconsole.dev/?g=groovy_5_0_alpha&codez=eNqFUctqwzAQvPsr9iYHWuEWcgkUCm0ogfQBST9AlTe2WnklVptHKfn3xnGcJuTQOUisZrSjHd0_sfnIVeBKV2ycT6Nuuzbpm-xoqAt9qwaZa2JggY7Te06_cWhcwtSTn2Zl9FKc1zaQXTIjiZ67BsNSxhuLUVygf8Xv5CTLrDcpwRyTAG4EqUwwi2jdwlnTtoGfDHZYBVeC2sti9xqQzhBqQ6V3VKl8cBC3WNdII1DmT14bATFfmMAHqpDbE9otx07qeLlFiQuIcAf98NoyGsFDeeLUI3nECDdFUVxQkR2JJ1A2NNGjYAkhntttz6qoK5R8WFxBn5R-nkynk9n44fXlcTbIjmrp5-zjQObAEOwu6nRuITWHNcHFR3X22-wX4JepOg

[matrei]

Yes, thrown seems to start breaking with 5.0.0-alpha-9.
I am currently testing the Grails codebase against 5.0.0-SNAPSHOT with Spock 2.4-M6-groovy-4.0.

It seems tests are annotated with @Ignore in the Groovy codebase because of this:
https://github.com/apache/groovy/blob/b70de711d79e75e7f813117d1240c219408b09d0/subprojects/groovy-contracts/src/test/groovy/org/apache/groovy/contracts/spock/SpockIntegrationTests.groovy#L31

[matrei]

Another breakage is with the Mock() method:

    void "test YamlCommandFactory readCommands"() {

        given: "A resource and profile"
        Resource mockCommandYml = Mock()
        TestYamlCommandFactory yamlCommandFactory = new TestYamlCommandFactory()

        when:
        mockCommandYml.getInputStream() >> new ByteArrayInputStream(getCommandYaml())
        mockCommandYml.filename >> "clean.yml"
        Map data = yamlCommandFactory.testReadCommandFile(mockCommandYml)

        then:
        data
        data.description == "Cleans a Grails application's compiled sources"
    }

ResourceProfileSpec > test YamlCommandFactory readCommands FAILED
    groovy.lang.MissingMethodException: No signature of method: org.grails.cli.profile.ResourceProfileSpec.MockImpl() is applicable for argument types: (String, Class) values: [mockCommandYml, interface org.grails.io.support.Resource]
    Possible solutions: Mock(), Mock(java.lang.Class), Mock(java.util.Map, java.lang.Class)
        at org.grails.cli.profile.ResourceProfileSpec.test YamlCommandFactory readCommands(ResourceProfileSpec.groovy:84)

[eric-milles]

Groovy 5 is enforcing the package-protected visibility of the implementation methods. I think some of these methods need to be protected or public:

spock/spock-core/src/main/java/org/spockframework/lang/SpecInternals.java

Line 73 in c55a818

<T extends Throwable> T thrownImpl(String inferredName, Class<T> inferredType) {

[jdaugherty]

I can confirm that switching the package private methods in this class to public fixes the Mock, etc issues

[leonard84]

The downside of increasing visibility is that the methods show up in the autocomplete. We might have to move them to a separate class and make them static.

[jdaugherty]

I started to look at the changes needed for Groovy 5. JDK 11 is now the minimum supported version for Groovy 5. Spock uses java versions back to 8 since it still publishes for Groovy 2.5. Would the Spock team drop Groovy 2.5 support or continue to maintain it?

[Vampire]

As long as there is no significant reason to drop the support, it should probably stay.

[jdaugherty]

If it still needs support, then the build will need reworked so that JDK8 is not used for the groovy 5 variant since the class version will mismatch. I started a branch with Eric's suggestions so I will proceed to see what other changes are needed then.

[Vampire]

Even if 2.5 would no longer be supported, that would still not mean that Java 8 supported can be dropped. Again, without really good reason this should not be dropped. :-)

[jdaugherty]

So I'm not sure how to proceed with this, _ is a reserved keyword as of Java 9 and Groovy 5 does not support Java 8. Spock got away with this before because it compiled with Java 8.

        spock-core/src/main/java/spock/lang/Specification.java:49: error: as of release 9, '_' is a keyword, and may not be used as an identifier
        public static final Object _ = Wildcard.INSTANCE;
                                   ^
      1 error

    * Try:
    > Check your code and dependencies to fix the compilation error(s)

[snicoll]

Thanks @Vampire. We're keen to upgrade to Groovy 5 in Spring Boot and our RC is in two weeks time. If that misses that deadline we'll have to stick with our current version. A compatible release of spock is currently holding us, and I am happy to test a snapshot once it is available.

[Vampire]

Even if I get the Groovy 5 support going, I guess at most an M-release would be done as there are a few issues that imho should tackled before a 2.4 GA release. 🤷‍♂️

[snicoll]

Alright, moving it out then.

[Vampire]

#2213, except that the mock integration tests don't work and there are two potential Groovy Bugs that must be checked first and some downstack PRs first :-)

[Vampire]

@snicoll the snapshot publishing was fixed, so now you could try out the snapshot version which has Groovy 5 support. :-)

[sdelamo]

I am working on migrating Micronaut to Apache Groovy 5 for Micronaut 5. We use Spock heavily. A Spock version compatible with Groovy 5 would be really awesome.

[JoMiPeCa]

Was referring to the main page of the repo — it says support starts from Java 11 to 17, and mentions Java 8 for Spock 2.4, which is a bit confusing in my opinion.

What I meant was the combination of Spock 4.0 with Groovy 5.0.

Thanks a lot for the test results link — it clarified everything ♥️

By the way, a small matrix/table on the main README showing Spock + Groovy + Java compatibility would be super helpful for newcomers.

Just an idea — something like this maybe:

Spock version	Groovy supported	Java supported
2.4 (M6)	2.5 · 3.0 · 4.0	8 +
2.5	2.5 · 3.0 · 4.0	8 · 11
3.0	2.5 · 3.0 · 4.0	8 · 11 · 17 · 21 · 25
4.0	2.5 · 3.0 · 4.0	8 · 11 · 17 · 21 · 25
5.0	2.5 · 3.0 · 4.0 · 5.0	11 · 17 · 21 · 25

Based on the current CI runs and the “Add Groovy 5 support” PR (#2196).

[Vampire]

I still have no idea what your are talking about.

Was referring to the main page of the repo — it says support starts from Java 11 to 17

I didn't know it find where it says that.
That would be non-sense, but it also is not there.
It says Spock supports Java 8+ and that's it.

What I meant was the combination of Spock 4.0 with Groovy 5.0.

At you talking about the right Spock project? Current version is 2.3, upcoming version is 2.4. 4.0 is not a thing, so "Spock 4.0 with Groovy 5.0" still makes not any sense at all.

Thanks a lot for the test results link — it clarified everything

Didn't sound like it did.

Just an idea — something like this maybe:

How would that help in any way?
Spock supports Java 8+ and from the variants you see exactly which Groovy versions are supported. I don't see how duplicating the same information again would clear up anything. Especially mit version that do not exist at all.

[JoMiPeCa]

Okay okay. I see your point. Apologize me, please.

The building process only mention idk 11 and 17.

My error (haven’t slept well in past 2 weeks and have been burning myself past 3 months) was to confuse 4.0 with 2.4 (yes. Huge difference. )

but yes. Test results clarified me a lot.

Regarding the table. I meant this:

Spock, Groovy, Java

Spock version	Groovy supported	Java supported
0.7 (legacy)	1.8 · 2.0	6 · 7 · 8
1.2	2.4	7 · 8 · 9
1.3	2.5 · 3.0	8 · 9 · 10 · 11
2.3 (current)	2.5 · 3.0 · 4.0	8 · 11 · 17 · 21 · 25
2.4 (M6)	2.5 · 3.0 · 4.0 · 5.0	11 · 17 · 21 · 25

📦 Based on Spock’s historical compatibility notes and the latest CI matrix
(GitHub Actions run #18761428274)
plus PR #2196 "Add Groovy 5 support"

[Vampire]

Honestly, I still think it has little value.
Noone should have a reason to use anything older than 2.3 and if really necessary, you can always look at the readme or docs of the older version, or the change log.

Also, the Java versions are not really restricted by Spock. Java is quite backwards compatible and we do not do things like reading class files, so Spock basically supports any Java version. Which do work is more limited by other things you use, like the Groovy version or libraries. That we support 8+ and not older is probably simply because the oldest Groovy version we support supports 8+ so there is no point in supporting older Java version. The upper bounds you mentioned are just what the tests run with, not what we support.

Which Groovy versions are supported should be pretty obvious from the version variants that exist. Once we maybe switch to publishing the variants under the same version, it might make sense. 🤷‍♂️

[Vampire]

@sdelamo the snapshot publishing was fixed, so now you could try out the snapshot version which has Groovy 5 support. :-)