Lokasi ngalangkungan proxy:   [ UP ]  
[Ngawartoskeun bug]   [Panyetelan cookie]                
Skip to content

Run tests on JDK 17 and JDK 25#153

Open
vbabanin wants to merge 11 commits intomongodb:mainfrom
vbabanin:HIBERNATE-140
Open

Run tests on JDK 17 and JDK 25#153
vbabanin wants to merge 11 commits intomongodb:mainfrom
vbabanin:HIBERNATE-140

Conversation

@vbabanin
Copy link
Copy Markdown
Member

@vbabanin vbabanin changed the title Add support for JDK 17 and JDK 25 in build configuration. Run tests on JDK 17 and JDK 25 Dec 12, 2025
@vbabanin vbabanin self-assigned this Dec 12, 2025
@vbabanin vbabanin marked this pull request as ready for review December 31, 2025 21:53
@vbabanin vbabanin requested a review from a team as a code owner December 31, 2025 21:53
@vbabanin vbabanin requested review from nhachicha and stIncMale and removed request for nhachicha December 31, 2025 21:53
Copy link
Copy Markdown
Member

@stIncMale stIncMale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last reviewed commit is ad6f26a.

Comment thread .evergreen/java-config.sh Outdated
# Java configurations for evergreen

export JDK17="/opt/java/jdk17"
export JDK25="/opt/java/jdk25"
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread .evergreen/java-config.sh
export JDK25="/opt/java/jdk25"

if [ -d "$JDK17" ]; then
export JAVA_HOME=$JDK17
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I doubt we need the JAVA_HOME variable, as I don't see us using it anywhere. And Gradle is capable of auto-detecting locations of installed JDKs.
  2. What's worse, is we always set JAVA_HOME to /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‎.

Copy link
Copy Markdown
Member Author

@vbabanin vbabanin Apr 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread .evergreen/config.yml
Comment on lines +249 to 256
- 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
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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'

and

[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}")
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread buildSrc/src/main/kotlin/project/base.gradle.kts Outdated
Comment thread buildSrc/src/main/kotlin/project/base.gradle.kts Outdated
Comment thread buildSrc/src/main/kotlin/project/Companion.kt Outdated
languageVersion.set(JavaLanguageVersion.of(testJavaVersion))
}
)
} No newline at end of file
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add the missing LINE FEED (LF) character at the end of this file.

@vbabanin
Copy link
Copy Markdown
Member Author

//TODO add assertion in test execution environment that env variable for Java version from CI is equals to current Java runtime version.

vbabanin and others added 4 commits March 29, 2026 22:33
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>
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.base precompiled Gradle plugin that pins compilation to Java 17 and selects the test JVM via -PjavaVersion.
  • Update Evergreen configuration to add a jdk axis (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.

Comment thread buildSrc/src/main/kotlin/project/base.gradle.kts Outdated
Comment thread .evergreen/java-config.sh
Comment thread buildSrc/src/main/kotlin/project/Constants.kt
Comment thread buildSrc/src/main/kotlin/project/base.gradle.kts Outdated
Comment on lines +49 to +51
tasks.withType<JavaExec>().configureEach {
javaLauncher.set(runtimeJavaLauncher)
}
Copy link
Copy Markdown
Member Author

@vbabanin vbabanin Apr 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread buildSrc/src/main/kotlin/project/base.gradle.kts Outdated
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants