Looks like I’ve misread the release notes.
Groovy 4.0 requires JDK16+ to build and JDK8 is the minimum version of the JRE that we support. Groovy has been tested on JDK versions 8 through 17.
16+ is probably required to build the Groovy jar, not to build your code.
Here’s a PR updating test runner dependencies to Groovy 4: Update test runner to Groovy 4 by artamonovkirill · Pull Request #40 · exercism/groovy-test-runner · GitHub
And here’s the one for exercism/groovy: Bump Groovy to version 4 by artamonovkirill · Pull Request #468 · exercism/groovy · GitHub
Quite some changes due to the bump of the Gradle wrapper version 
How can we get this reviewed?
It’s a lot of files, but 80% are generated (gradle-wrapper.jar, gradle-wrapper.properties, gradlew, gradle.bat)
Thanks for this!
How, and to what extent, have you tested it all works? Both locally and with the groovy-test-runner?
I relied on the CI:
./gradlew wrapper command was run and all wrapper files are up to dateRunning with the test runner is of no use for this PR, as the test runner’s dependency management is fully isolated (even uses Maven, not Gradle and is on Groovy 4 already). The test runner was tested in the previous PR, though: Update test runner to Groovy 4 by artamonovkirill · Pull Request #40 · exercism/groovy-test-runner · GitHub
P.S. When running locally, I have a little issue with list-ops reference solution, but according to stackoverflow, it’s related to JDK flavor, not Groovy or Spock version.
OK, so instinctively I’d be happy to wave this through if you’re confident. I’ll ask maintainers if anyone objects or has feedback!
(@ErikSchierboom Any thoughts?)
It has already been merged by @glennj 
I also briefly checked locally:
⋊> ~/w/e/g/hello-world ./gradlew clean build 17:44:47
> Task :test
HelloWorldSpec > Say Hi! > HelloWorldSpec.Say Hi! [expected: Hello, World!, #0] PASSED
BUILD SUCCESSFUL in 2s
5 actionable tasks: 5 executed
Ha. OK. Awesome.
And now the last remaining part: bumping the Docker JDK version to make the latest Java features like records available. There are a few issues, though:
maven:<...>-jdk-<...> (the flavor the runner currently uses) is Java 14slim image is 3.8.5-openjdk-17-slim, but the base openJDK image has been deprecatedIt seems to work with Java 21 and alpine image: Bump JDK to 21 by artamonovkirill · Pull Request #43 · exercism/groovy-test-runner · GitHub
Would it make sense to use a different JDK flavor?
I’m also not sure why was --legacy-local-repository flag needed
Great work!
I know nothing about the Java world, so I have no idea. Sorry!
This smells like something to do with the test runner not having internet in production.
This smells like something to do with the test runner not having internet in production.
The very last comment in [MNG-7713] Drop option legacy-local-repository - ASF JIRA also suggests something regarding internet access, but I just ran ./bin/run-reference-solution-tests-in-docker.sh (without re-building the Docker image) on my laptop with WiFi turned off, and it didn’t fail. And there’s already a --offline flag in the maven command. Am I missing something?
There can just be a lot of subtleties. For example, for Elixir, you have to give it a network device to detect (but no actual internet), otherwise it hangs for 20 seconds waiting for network.
If it’s not doing anything harmful, I’d just leave it personally. Chesterton’s Fence etc. But if it’s causing a problem, we can investigate more.
maven command fails with Unsupported options: Option '-llr' is not supported starting with Maven 3.9.1 
Is there a way to simulate the test runner environment as on the website or run it one-off with a different Docker image?
Git history (Switch to Maven by andreaTP · Pull Request #18 · exercism/groovy-test-runner · GitHub) says -llr was added in a single commit with maven migration, so it must have been somehow tested while working on that commit 
I did some more reading on the -llr flag, and some sources suggest the flag might be needed on environments with multiple Maven processes might run simultaneously, but I guess that’s not the case for the test runner, right?
Not really, no. So bin/run-tests-in-docker.sh worked on your machine? Is that a mac,.a linux or windows machine?
I ran it on mac air
Before I create a roll-back PR: is the new image pushed to the workers automatically? Or is it expected to have a few timeouts once the image is updated?
Yay! Thanks.
One more PR to allow solving exercises locally with Java 21: Bump Gradle to 8 by artamonovkirill · Pull Request #470 · exercism/groovy · GitHub 
