Upgrade a Spring Boot App to Java 25

The agent clones the repository into its own cloud sandbox and finds every place the Java version is written down, because a version upgrade that misses one of them passes locally and fails somewhere else. In a project like spring-projects/spring-petclinic there are two builds side by side. pom.xml inherits from spring-boot-starter-parent 4.1.0 and sets <java.version>17</java.version>, which also feeds the maven-enforcer-plugin rule requireJavaVersion and the java.source and java.target values written into build-info. build.gradle applies the org.springframework.boot plugin 4.1.0 and sets a toolchain with JavaLanguageVersion.of(17). The wrappers are Maven 3.9.16 in .mvn/wrapper/maven-wrapper.properties and Gradle 9.5.1 in gradle/wrapper/gradle-wrapper.properties, and the agent checks that both run on a JDK 25 before touching anything else.

Next it reads the plugins that care about the bytecode version. JaCoCo is pinned at 0.8.15 and instruments every test class; the GraalVM native build tools, spring-javaformat 0.0.47 and the CycloneDX plugin all run during the build. Checkstyle is held at 12.3.1, with a comment in pom.xml saying it stays on 12 because Checkstyle 13 needs JDK 21. On Java 25 that reason is gone, so the agent says so in the pull request and leaves the bump as a separate decision rather than mixing it into the JDK change. It moves the version in one place per build: java.version to 25 in pom.xml and the toolchain to JavaLanguageVersion.of(25) in build.gradle.

Then it updates what runs the build outside the sandbox. .github/workflows/maven-build.yml and gradle-build.yml both use a java: [ '17' ] matrix with actions/setup-java@v4 and distribution: 'adopt', which setup-java has removed in favour of temurin, so the agent switches the distribution to temurin and the matrix to 25. It notes that gradle-build.yml caches with cache: maven even though it runs ./gradlew build, and changes it to gradle. There is no Dockerfile (the README builds images with ./mvnw spring-boot:build-image), but .devcontainer/Dockerfile defaults to VARIANT=17-bullseye for Gitpod and devcontainer.json asks for Java 21-oracle, so the agent updates both or explains why one stays.

Finally it builds and tests on JDK 25 with both tools: ./mvnw -B verify, which runs the enforcer, the javaformat check and the nohttp Checkstyle rules before the tests, and ./gradlew build. The project has 20 test classes. MySqlIntegrationTests is marked @Testcontainers(disabledWithoutDocker = true) and PostgresIntegrationTests assumes DockerClientFactory.instance().isDockerAvailable(), so the agent reports whether those two ran or were skipped in the sandbox; the workflows on the pull request run them on GitHub's runners. When a compile error, a deprecation that is now an error or a failing test appears, it fixes the cause, runs the suite again, and only then opens the pull request.

What comes back is a pull request on a new branch. In a project shaped like spring-petclinic it changes pom.xml and build.gradle to Java 25, both workflow files to temurin with a Java 25 matrix (and the Gradle workflow's cache to gradle), and the devcontainer files, plus any source or test fixes the new JDK forced. The description lists each changed file with the reason, every compile or test failure the agent hit with the fix it made, the tests that were skipped in the sandbox and why, and the follow-ups it chose not to mix in, such as moving Checkstyle to 13.

The pull request's own checks are the proof that matters: the Maven and Gradle workflows it edits run on it with JDK 25, including the Testcontainers tests on a runner with Docker. The session's transcript keeps every command the agent ran in its sandbox, from java -version to each ./mvnw -B verify and ./gradlew build, with the output.

Before merging, a reviewer checks that the JDK distribution matches what the team deploys on, that the base image used in production (built by spring-boot:build-image or elsewhere) will also run Java 25, that any --add-opens flag or suppressed warning the agent added has a reason in the description, and that both workflows passed on the pull request rather than only one.

Java ships a feature release every March and September. A scheduled job on your server can send this request with the new version in the prompt once your JDK vendor publishes it, one request per repository, each with that repository in resources. Each run gets its own sandbox and opens its own pull request, so a team with many Spring Boot services sees which ones move cleanly and which need work.

Set a webhook URL on the API key and Rush POSTs run.completed or run.failed when each run's turn finishes, with the session_url. A key runs at most max_concurrent sessions at once (4 by default) and answers 429 past that, so a job covering many repositories should queue its requests.

A JDK upgrade touches the machine as much as the code: a new JDK, both wrappers downloading their distributions, every dependency resolved again, and a full test run that has to happen on the new version and not on whatever JAVA_HOME points at on a laptop. In a Rush sandbox the agent installs and uses JDK 25 on its own disk, so no one's local toolchain changes and the build is not quietly running on Java 17.

The proof is in two places. The transcript keeps each ./mvnw and ./gradlew run with its output, and the pull request's workflows run the same builds on JDK 25 on GitHub. A reviewer can see that the upgrade was built and tested on the new version rather than taken on trust, and several services can be upgraded at once, each in its own sandbox.

My project has both Maven and Gradle builds. Does it update both?

Will it upgrade Spring Boot at the same time?

What about integration tests that need Docker?

Why switch the setup-java distribution?