[gortazar]

Moves the repository from Java 21 to Java 25, the current LTS. Spring Boot 4.0.5 supports it.

I have not run the tests locally. The matrix on this branch is the verification.

60a917f — querydsl-apt as an annotation processor path

bd_ejem17 relied on javac finding the processor on the compile classpath, which is how querydsl-apt was wired: a provided dependency and nothing else. From JDK 23 javac no longer runs processors discovered that way, so QPost silently stops being generated and the project fails with cannot find symbol. It is the only project in the repository with an annotation processor, and it is the reason this bump is not a one-line change.

annotationProcessorPaths states the processor explicitly. The path needs jakarta.persistence-api too, since the JPA processor resolves the persistence annotations from the processor path rather than the classpath. The provided dependency stays: Eclipse and IDEA still discover the processor through the classpath.

No behaviour change on Java 21, so this commit is safe on its own.

632e0c5 — Java 25 everywhere

• java.version in all 86 poms, plus the maven.compiler.source/target pair in parte_4/tema_4.2/ejemplo-2, which has no Boot parent.
• maven-build.yml sets up JDK 25.
• The Docker samples: eclipse-temurin:25-jre at runtime, maven:3.9.11-eclipse-temurin-25 to build. There is no maven:3.9.9-eclipse-temurin-25 tag, so the pinned Maven version moves with it.

Three Dockerfiles were already behind their own pom and are consistent for the first time: parte_4/tema_4.2/ejer4 and parte_4/tema_4.3/ejercicio-1 built a java.version 21 project on a JDK 17 image, and parte_5/ejem4b-haproxy-ssl-passthrough ran the resulting jar on a 17.0.6 JRE. CI only runs Maven, so none of that is exercised here — it failed only for whoever built the images.

The defaults of update-springboot.yml said Boot 3.4.1 and Java 17, so dispatching that workflow with its own defaults would have downgraded the repository. They now match what it is on. Say the word if you would rather leave that file alone.

Left alone

The devcontainer in parte_4/tema_4.2/ejemplo-1 pins VARIANT to 17-bullseye on the deprecated mcr.microsoft.com/vscode/devcontainers/java image, whose :0- tag family has no 25. Fixing it means moving to mcr.microsoft.com/devcontainers/java, which is a different change and not covered by CI either way.

What to watch in this run

Java 25 enforces two things that were warnings on 21: sun.misc.Unsafe memory-access methods, and dynamic agent loading. If anything fails, Mockito and ByteBuddy inside spring-boot-starter-test are the first place to look, and the 21 Testcontainers projects the second.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[gortazar]

Two follow-ups: cache reuse and the devcontainer

0697847 — fill the Maven cache once instead of 86 times at once

The first run on a branch has no cache, so all 86 build jobs started downloading from Maven Central at the same time and it answered HTTP 429. That is what failed parte_4/tema_4.3/ejemplo-2 on the previous attempt of this PR: spring-boot-maven-plugin:pom:4.0.5 could not be transferred, with nothing wrong in the project. A rerun passed, which is the signature of throttling rather than a build problem.

A warm-cache job now resolves every project once and build depends on it. The cache key setup-java derives from the hash of the pom files is identical across the jobs of a run, so the 86 restore what that one job saved. actions/cache only writes on a miss, so they do not race to save it either.

Warming is an optimisation, not a gate: a project that fails to resolve there produces a warning and the matrix still runs, because the verdict belongs to the build jobs. dependency:go-offline also misses what gets resolved at test time, such as the surefire provider, so the build step keeps a retry handler for the few requests that still go out.

Measured on this run:

Warm the Maven cache	6 min 16 s, once
A build job afterwards	~32 s, no downloads
Projects that failed to resolve	0

8b50f09 — a devcontainer image that still exists

parte_4/tema_4.2/ejemplo-1 pinned VARIANT to 17-bullseye on mcr.microsoft.com/vscode/devcontainers/java, whose :0- tag family stops at 17 — there is no 25 to move to, so bumping the argument was not an option. It now uses mcr.microsoft.com/devcontainers/java:3-25-bookworm, the image that replaced it, with Maven from the java feature at version: none so the feature adds Maven without installing a second JDK over the image's own.

The Dockerfile is gone: it existed only to turn INSTALL_MAVEN, INSTALL_GRADLE and NODE_VERSION into sdkman and nvm calls, which is what features do now.

Two more things it carried: settings and extensions sat at the top level, which the spec moved under customizations.vscode, and java.home pointed at /docker-java-home, a path the current images do not have. A wrong java.home breaks the Java extension, so it is dropped rather than updated — the extension reads JAVA_HOME.

Nothing in CI builds a devcontainer, so this part is unverified by the matrix. The image tag was checked against the MCR tag list and the feature options against the feature definition, not by opening the container.

Unrelated, flagged by this run

GitHub is warning that actions/setup-java@v4 is deprecated and that actions/checkout@v4 and setup-java@v4 target Node 20, which runners now force onto Node 24. Moving both to @v5 is a separate change.