Upgrading Groovy and Java

Programming Groovy
1

I noticed that Groovy and Java versions in the Groovy test runner are outdated (Groovy 3 and Java 11), so no recent features are supported, like records or switch expressions.
Updating both is quite an endeavor:

  • Groovy 4 requires JDK 16+ to build
  • Groovy changed its package groupId since version 4
  • Groovy deprecated groovy-all activate since version 4
  • The Spock version is also dependent on the Groovy version.

But since groovy-test-runner is pretty independent of exercises’ Gradle configs (it runs on maven with its own pre-downloaded list of dependencies), I think it should be possible to bump the runner first (and have the exercise dependency update PR ready too to merge shortly after).
There aren’t any deprecated language features, at least according to the release notes.

Does anyone have any concerns already?

I’m planning to at least check reference Groovy exercises solutions to pass the tests to get some estimate of backwards compatibility.

3 Likes
2

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.

:point_up: 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

1 Like
3

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 :disappointed:

2 Likes
4

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)

5

Thanks for this!

How, and to what extent, have you tested it all works? Both locally and with the groovy-test-runner?

6

I relied on the CI:

  • build job will run the tests, plus the root gradle project is set up to unignore the tests and use reference solutions as source: config
  • the validation CI job ensures that the ./gradlew wrapper command was run and all wrapper files are up to date

Running 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.

7

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?)

8

It has already been merged by @glennj :hugs:
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
9

Ha. OK. Awesome.

10

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:

  • latest available maven:<...>-jdk-<...> (the flavor the runner currently uses) is Java 14
  • latest available slim image is 3.8.5-openjdk-17-slim, but the base openJDK image has been deprecated

It 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

1 Like
11

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.

12

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?

1 Like
13

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.

14

maven command fails with Unsupported options: Option '-llr' is not supported starting with Maven 3.9.1 :sweat_smile:

15

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 :thinking:
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?

16

Not really, no. So bin/run-tests-in-docker.sh worked on your machine? Is that a mac,.a linux or windows machine?

17

I ran it on mac air

18

Screenshot 2025-01-20 at 17.47.25
Screenshot 2025-01-20 at 17.47.25928×486 44.1 KB

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?

19

:partying_face:

Screenshot 2025-01-20 at 17.49.49
Screenshot 2025-01-20 at 17.49.49934×1202 94.6 KB

I tested a few more exercises, none timed out

20

Yay! Thanks.