Run tests on JDK 17 and JDK 25#153
Conversation
| # Java configurations for evergreen | ||
|
|
||
| export JDK17="/opt/java/jdk17" | ||
| export JDK25="/opt/java/jdk25" |
There was a problem hiding this comment.
Why do we need the JDK25 variable? It is not used by anything in our codebase. There is still a chance that it is used by a subsequently executed command, because export marks a "name to be passed to subsequently executed commands in the environment", but I don't have reasons to believe that is what happens in our case.
| export JDK25="/opt/java/jdk25" | ||
|
|
||
| if [ -d "$JDK17" ]; then | ||
| export JAVA_HOME=$JDK17 |
There was a problem hiding this comment.
- I doubt we need the
JAVA_HOMEvariable, as I don't see us using it anywhere. And Gradle is capable of auto-detecting locations of installed JDKs. - What's worse, is we always set
JAVA_HOMEto/opt/java/jdk17, if the directory exists, which is not what we want in this PR.
I suspect, we can and should just remove java-config.sh.
There was a problem hiding this comment.
JAVA_HOME isn’t used by the build logic once Gradle is running - agreed. Gradle toolchains handle JDK selection for compilation/tests.
However, JAVA_HOME is used by gradlew to decide which JVM launches the Gradle daemon. On rhel80 the jdk in the PATH is JDK 8 (/usr/lib/jvm/java-1.8.0-openjdk), and Gradle 9+ won’t start on JDK 8 (“Gradle requires JVM 17 or later…”). So setting JAVA_HOME here is only to bootstrap Gradle itself on CI.
There are other ways to do this (e.g., org.gradle.java.home=/opt/java/jdk17), but that can affect local builds. Using JAVA_HOME in separate script looks cleaner.
Regarding removing java-config.sh: we could remove it, but I’d prefer to keep it to avoid duplicating the same bootstrap logic (setting JAVA_HOME when JDK17 is available, JAVA_VERSION default, and diagnostic output) across the 5 CI scripts (static-checks, run-unit-tests, run-smoke-tests, run-integration-tests, publish). With a shared script, each one just needs source java-config.sh.
I currently added comments in java-config.sh to make the purpose of JAVA_HOME explicit.
| - matrix_name: unit-tests | ||
| matrix_spec: { jdk: "*" } | ||
| tags: | ||
| - pr | ||
| display_name: "Unit Tests" | ||
| display_name: "Unit Tests ${jdk}" | ||
| run_on: rhel80-medium | ||
| tasks: | ||
| - name: run-unit-tests |
There was a problem hiding this comment.
This does not seem to work. The Unit Tests JDK25 build variant logs
2025/12/11 21:19:51.647] ++ export JAVA_HOME=/opt/java/jdk17
[2025/12/11 21:19:51.647] ++ JAVA_HOME=/opt/java/jdk17
[2025/12/11 21:19:51.647] ++ export JAVA_VERSION=17
[2025/12/11 21:19:51.647] ++ JAVA_VERSION=17
[2025/12/11 21:19:51.647] ++ echo 'Java Configs:'
[2025/12/11 21:19:51.647] ++ echo 'Java Home: /opt/java/jdk17'
[2025/12/11 21:19:51.647] ++ echo 'Java test version: 17'
[2025/12/11 21:21:18.654] Running tests using using JDK17
While JAVA_HOME is expected to be broken (I commented on it in VAKOTODO "I doubt we need the"), having incorrect JAVA_VERSION is surprising, as java-config.sh sets it only if it is unset or null (see the :- parameter expansion).
Also, you may see here that Gradle emits all auto-detected JDKs/JREs, and JDK 25 does no appear to be installed. We may need to ask someone to do the changes necessary so that it becomes available (I don't know what the process is).
| `java-library` | ||
| } | ||
|
|
||
| logger.info("Compiling ${project.name} using JDK${RELEASE_JAVA_VERSION}") |
There was a problem hiding this comment.
Let's say "Building" instead of "Compiling"? Because really, compiling is not the only thing that happens: there are static checkers that are run, there is generation of API documentation, etc.
| languageVersion.set(JavaLanguageVersion.of(testJavaVersion)) | ||
| } | ||
| ) | ||
| } No newline at end of file |
There was a problem hiding this comment.
Let's add the missing LINE FEED (LF) character at the end of this file.
|
//TODO add assertion in test execution environment that env variable for Java version from CI is equals to current Java runtime version. |
Co-authored-by: Valentin Kovalenko <valentin.male.kovalenko@gmail.com>
Co-authored-by: Valentin Kovalenko <valentin.male.kovalenko@gmail.com>
Co-authored-by: Valentin Kovalenko <valentin.male.kovalenko@gmail.com>
There was a problem hiding this comment.
Pull request overview
Adds multi-JDK CI coverage by parameterizing the test runtime JDK (while keeping compilation pinned to the release JDK) and introducing an Evergreen matrix to run tests on JDK 17 and JDK 25.
Changes:
- Introduce a
project.baseprecompiled Gradle plugin that pins compilation to Java 17 and selects the test JVM via-PjavaVersion. - Update Evergreen configuration to add a
jdkaxis (17/25) and run unit/integration tests across that matrix. - Adjust Evergreen Java bootstrap to always launch Gradle with JDK 17 and pass the desired test JDK version through to Gradle.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| buildSrc/src/main/kotlin/project/base.gradle.kts | New precompiled script plugin configuring toolchains and per-test JVM selection. |
| buildSrc/src/main/kotlin/project/Companion.kt | Defines the release Java version constant used by the plugin. |
| build.gradle.kts | Applies the new project.base plugin at the root build. |
| .evergreen/java-config.sh | Forces Gradle bootstrap via JDK 17; keeps JAVA_VERSION defaulting to 17. |
| .evergreen/config.yml | Adds a JDK axis and matrices unit/integration tests across JDK 17 and JDK 25. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| tasks.withType<JavaExec>().configureEach { | ||
| javaLauncher.set(runtimeJavaLauncher) | ||
| } |
There was a problem hiding this comment.
Unlike Test, JavaCompile, and Javadoc, JavaExec tasks don’t inherit the project toolchain - they silently fall back to the Gradle daemon JDK. That’s not obvious and can be easy to miss, so wiring the toolchain manually in each future JavaExec usage is error-prone. Adding this now is a low-cost guardrail that prevents that class of mistake upfront.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
HIBERNATE-140