fix: Update to Jdk 25 #466
Conversation
# Conflicts: # buildSrc/build.gradle.kts # gradle/libs.versions.toml
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughBumps Java/Kotlin targets from 21 → 25 across SDK, Docker base image, and Gradle convention plugins; adds test-convention plugin, test dependencies and a basic Spring Boot context-load test; adds a Kotlin bootstrap Maven repository and updates buildSrc dependency references and formatting. Changes
Sequence Diagram(s)(omitted — changes are build/config/test additions and do not alter runtime control flow) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
Dockerfile (1)
35-37: Optional: add a HEALTHCHECK for container readinessHelps ops detect failing instances.
Example:
ENTRYPOINT ["java","-jar","./app.jar"] EXPOSE 8080 + +HEALTHCHECK --interval=30s --timeout=3s --start-period=30s --retries=3 \ + CMD wget -qO- http://127.0.0.1:8080/actuator/health | grep '"status":"UP"' || exit 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
server/src/test/resources/application.ymlis excluded by!**/*.yml
📒 Files selected for processing (8)
.sdkmanrc(1 hunks)Dockerfile(2 hunks)buildSrc/build.gradle.kts(1 hunks)buildSrc/src/main/kotlin/hu/bsstudio/gradle/JavaConventionPlugin.kt(1 hunks)buildSrc/src/main/kotlin/hu/bsstudio/gradle/JavaLibraryConventionPlugin.kt(1 hunks)buildSrc/src/main/kotlin/hu/bsstudio/gradle/KotlinConventionPlugin.kt(1 hunks)server/build.gradle.kts(2 hunks)server/src/test/kotlin/hu/bsstudio/bssweb/BssWebApplicationTest.kt(1 hunks)
🧰 Additional context used
🪛 GitHub Check: Scorecard
Dockerfile
[warning] 1-1: Pinned-Dependencies
score is 9: containerImage not pinned by hash
Click Remediation section below to solve this issue
🔇 Additional comments (7)
.sdkmanrc (1)
3-3: Fix SDKMAN entry (remove stray space).The extra space after '=' can break auto-env.
Apply:
-java= 25-librca +java=25-librcabuildSrc/src/main/kotlin/hu/bsstudio/gradle/JavaLibraryConventionPlugin.kt (1)
18-18: Java 25 toolchain for libraries: LGTM; same Gradle-compatibility caveatLooks good. Same verification as the main Java convention plugin: ensure the Gradle wrapper can run on JDK 25.
See the wrapper check script in the other comment.
server/build.gradle.kts (2)
7-7: Test convention plugin: LGTMGood addition to centralize test configuration.
18-21: Keep explicit Testcontainers deps — the test convention plugin doesn't add themTestConventionPlugin / IntegrationTestConventionPlugin only add spring-boot-starter-test, junit-platform-launcher, mockk, springmockk and kotest (in buildSrc); they do not add org.testcontainers or org.springframework.boot:spring-boot-testcontainers, so keep the testImplementation entries in server/build.gradle.kts (lines 18–21).
Likely an incorrect or invalid review comment.
Dockerfile (1)
1-1: Pin the build stage base image by digestThe app stage is pinned by sha256, but the build stage isn’t. Pinning both stages prevents supply‑chain drift.
Proposed change (replace with the exact one for this tag):
-FROM bellsoft/liberica-runtime-container:jdk-25_37-crac-cds-musl AS build +FROM bellsoft/liberica-runtime-container:jdk-25_37-crac-cds-musl@sha256:<digest> AS buildIf needed, look up the digest on the image registry page for the exact tag.
What is the sha256 digest for Docker image bellsoft/liberica-runtime-container:jdk-25_37-crac-cds-musl?server/src/test/kotlin/hu/bsstudio/bssweb/BssWebApplicationTest.kt (1)
6-11: No action required — spring-boot-starter-test is provided by the test convention pluginbuildSrc/TestConventionPlugin.kt adds org.springframework.boot:spring-boot-starter-test to the "test" JvmTestSuite; buildSrc/IntegrationTestConventionPlugin.kt also adds it for "integrationTest".
buildSrc/build.gradle.kts (1)
14-19: Kotlin 2.3.0 bump — align root plugin and add mavenCentral to buildSrc
- Root build: confirm the Kotlin plugin/version resolves to 2.3.0 (check root build.gradle(.kts), settings or libs.versions.toml).
- buildSrc/build.gradle.kts: repositories currently only contain gradlePluginPortal() — add mavenCentral() so kotlin-reflect and stdlib-jdk8 resolve.
Docstrings generation was requested by @csikb. * #466 (comment) The following files were modified: * `buildSrc/src/main/kotlin/hu/bsstudio/gradle/JavaConventionPlugin.kt` * `buildSrc/src/main/kotlin/hu/bsstudio/gradle/JavaLibraryConventionPlugin.kt` * `buildSrc/src/main/kotlin/hu/bsstudio/gradle/KotlinConventionPlugin.kt`
|
Note Generated docstrings for this pull request at #470 |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
.sdkmanrc (1)
3-3: SDKMAN target aligned to JDK 25 — looks good.This matches the toolchain bump across the repo.
Consider documenting “sdk env” usage in README so contributors auto-switch/install JDK 25 on cd.
Dockerfile (3)
7-7: Make Gradle bootstrap deterministic and cache-friendly.Running
./gradlewbefore copying settings/build scripts doesn’t prime dependency caches. Either just bootstrap the wrapper, or reorder.Option A (simple wrapper bootstrap):
-RUN ./gradlew +RUN ./gradlew --version --no-daemonOption B (prime dependencies): move this RUN after copying
settings.gradle.ktsand all*/build.gradle.ktsfiles.
34-34: Ensure correct ownership of the JAR for the non-root user.COPY defaults to root ownership; set chown for clarity and to avoid future write/perm quirks.
-COPY --from=build $BOOT_JAR ./app.jar +COPY --from=build --chown=spring:spring $BOOT_JAR ./app.jar ```<!-- review_comment_end --> --- `35-35`: **Optional JVM ergonomics in containers.** Consider setting memory flags for better behavior in k8s: `-XX:MaxRAMPercentage=75 -XX:InitialRAMPercentage=50` and add a basic HEALTHCHECK. Example: ```diff -ENTRYPOINT ["java","-jar","./app.jar"] +ENTRYPOINT ["java","-XX:MaxRAMPercentage=75","-XX:InitialRAMPercentage=50","-jar","./app.jar"] + +HEALTHCHECK --interval=30s --timeout=3s --start-period=30s --retries=3 \ + CMD wget -qO- http://localhost:8080/actuator/health | grep -q '"status":"UP"' || exit 1 ```<!-- review_comment_end --> </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: CodeRabbit UI **Review profile**: CHILL **Plan**: Pro <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 373be782ece8c9bbb234e7fb2c1b22ada073fa7c and 4e60d29bc1f1c0c0c377c5a560958367a17f0d62. </details> <details> <summary>📒 Files selected for processing (2)</summary> * `.sdkmanrc` (1 hunks) * `Dockerfile` (1 hunks) </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🪛 GitHub Check: Scorecard</summary> <details> <summary>Dockerfile</summary> [warning] 1-1: Pinned-Dependencies score is 9: containerImage not pinned by hash Click Remediation section below to solve this issue </details> </details> </details> <details> <summary>🔇 Additional comments (2)</summary><blockquote> <details> <summary>Dockerfile (2)</summary><blockquote> `32-35`: **Verify the JAR wildcard matches exactly one file.** If multiple JARs exist (e.g., plain + boot), COPY to a single file will fail. Run locally/CI and confirm only one match under `server/build/libs/`. If not, either disable `jar { enabled = false }` in Gradle or narrow the pattern (e.g., `*-boot.jar`), then: ```diff -ARG BOOT_JAR=$BUILD_ROOT/server/build/libs/*.jar +ARG BOOT_JAR=$BUILD_ROOT/server/build/libs/*-boot.jar
1-1: Pin the build-stage base image by digest.Security scanners flag unpinned base images; pin jdk-25-cds-musl like you did for the app stage.
Apply:
-FROM bellsoft/liberica-runtime-container:jdk-25-cds-musl AS build +FROM bellsoft/liberica-runtime-container:jdk-25-cds-musl@sha256:<digest> AS buildReplace with the exact sha256 of the image you intend to use (same registry/tag).
✅ Actions performedSummary regeneration triggered. |
…for conditional platform setting
|
# Conflicts: # .github/workflows/gradle.yml # .github/workflows/scorecard.yml # Dockerfile # buildSrc/build.gradle.kts
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
Dockerfile (1)
20-40: Add HEALTHCHECK instruction to the runtime stage.A HEALTHCHECK directive would improve container orchestration and observability by allowing the system to detect unhealthy container instances.
Consider adding:
FROM bellsoft/liberica-runtime-container:jre-25-cds-musl@sha256:445d46f3828e4e8683b2a19b59e4546a612d10f9ba6abbec2a01fd0ca0a2cc58 AS app # use non-root user RUN addgroup -S spring && adduser -S spring -G spring USER spring:spring WORKDIR /home/spring # copy jar and run it ARG BUILD_ROOT=/usr/src/app ARG BOOT_JAR=$BUILD_ROOT/server/build/libs/*.jar COPY --from=build $BOOT_JAR ./app.jar +HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \ + CMD java -cp ./app.jar org.springframework.boot.loader.JarLauncher --spring.boot.actuate.health 2>&1 | grep -q UP || exit 1 ENTRYPOINT ["java","-jar","./app.jar"]Adjust the health check command based on your application's actuator endpoints and requirements.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
.github/workflows/gradle.ymlis excluded by!**/*.yml
📒 Files selected for processing (2)
Dockerfile(1 hunks)settings.gradle.kts(1 hunks)
🧰 Additional context used
🪛 Checkov (3.2.334)
Dockerfile
[low] 1-40: Ensure that HEALTHCHECK instructions have been added to container images
(CKV_DOCKER_2)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Integration test
- GitHub Check: Build and publish
🔇 Additional comments (1)
settings.gradle.kts (1)
1-14: LGTM!The file structure and project configuration remain unchanged. The added blank line is a minor formatting adjustment with no functional impact.
Dockerfile
Outdated
| @@ -1,4 +1,4 @@ | |||
| FROM bellsoft/liberica-runtime-container:jdk-21.0.9_11-cds-musl@sha256:9fa29c32825076ee981ea9b9e73b84cc70d9ee5411bbad5f2881a97362c894f9 AS build | |||
| FROM bellsoft/liberica-runtime-container:jdk-25-cds-musl@sha256:450594440bb32b72f281e50626b629f1cc60caeb7796638bc570b9fab03e55ee AS build | |||
There was a problem hiding this comment.
🧩 Analysis chain
Verify the Docker image hashes are correct.
The base images have been updated to JDK 25 with new SHA256 hashes. While Liberica Runtime Container (Liberica Lite with Alpaquita Linux) supports JDK 25 as an LTS version, the new hashes must be verified as authentic to prevent supply-chain risks.
Please confirm these hashes by running:
Also ensure that the application is tested and verified to work correctly with Java 25, as this is a major version upgrade from JDK 21.
Also applies to: 29-29
🏁 Script executed:
#!/bin/bash
# Description: Verify Docker image hashes for jdk-25 and jre-25 images
# Expected: SHA256 digest matches the pinned hashes in Dockerfile
# For build stage image (jdk-25-cds-musl)
docker pull bellsoft/liberica-runtime-container:jdk-25-cds-musl 2>&1 | grep "Digest:"
# For runtime stage image (jre-25-cds-musl)
docker pull bellsoft/liberica-runtime-container:jre-25-cds-musl 2>&1 | grep "Digest:"Length of output: 0
🏁 Script executed:
#!/bin/bash
# Description: Query Docker Hub API for image digest information
# Alternative approach: use Docker Hub API to verify the image tags and their digests
# For jdk-25-cds-musl image
echo "=== Checking jdk-25-cds-musl ==="
curl -s "https://hub.docker.com/v2/repositories/bellsoft/liberica-runtime-container/tags/jdk-25-cds-musl/" | head -100
echo ""
echo "=== Checking jre-25-cds-musl ==="
curl -s "https://hub.docker.com/v2/repositories/bellsoft/liberica-runtime-container/tags/jre-25-cds-musl/" | head -100Length of output: 2344
Update the jdk-25-cds-musl image hash—current hash does not match Docker Hub.
The jre-25-cds-musl hash is correct, but the jdk-25-cds-musl hash is invalid:
- Dockerfile:
450594440bb32b72f281e50626b629f1cc60caeb7796638bc570b9fab03e55ee - Docker Hub:
3726c869b95563c00a642d52fc06afdc649ac3071cad160152846515597b6ab1
Update line 1 to use the correct hash. This will prevent build failures and supply-chain risks.
🧰 Tools
🪛 Checkov (3.2.334)
[low] 1-40: Ensure that HEALTHCHECK instructions have been added to container images
(CKV_DOCKER_2)
🤖 Prompt for AI Agents
In Dockerfile around lines 1 to 1, the FROM image uses an incorrect digest for
bellsoft/liberica-runtime-container:jdk-25-cds-musl; replace the existing
sha256:450594440bb32b72f281e50626b629f1cc60caeb7796638bc570b9fab03e55ee with the
correct digest
sha256:3726c869b95563c00a642d52fc06afdc649ac3071cad160152846515597b6ab1 so the
base image matches Docker Hub and avoids build failures and supply-chain risks.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
buildSrc/build.gradle.kts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Build and publish
- GitHub Check: Build
- GitHub Check: Integration test
🔇 Additional comments (1)
buildSrc/build.gradle.kts (1)
14-19: I need to verify the claims in the embedded verification section. Let me search for information about Kotlin version compatibility with Java 25.
Kotlin 2.3.0-Beta2 adds support for Java 25. The current stable version of Kotlin is 2.2.21, which supports Java 24 bytecode—not Java 25. When Kotlin 2.2.x is used with Java 25, it produces a warning "Kotlin does not yet support 25 JDK target, falling back to Kotlin JVM_24 JVM target", confirming that the beta version is necessary to properly target Java 25.
The use of Kotlin 2.3.0-Beta2 is justified for this JDK 25 upgrade. While beta versions do carry inherent risk, there is currently no stable Kotlin release that supports Java 25, making the beta version the only option for this migration.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
gradle/libs.versions.tomlis excluded by!**/*.toml
📒 Files selected for processing (1)
buildSrc/build.gradle.kts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Integration test
- GitHub Check: Build and publish
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
buildSrc/build.gradle.kts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Build and publish
buildSrc/build.gradle.kts
Outdated
| // TODO: remove when detekt stable is in gradle plugin portal | ||
| maven { | ||
| // https://central.sonatype.org/publish/publish-portal-snapshots/#consuming-via-gradle | ||
| url = uri("https://central.sonatype.com/repository/maven-snapshots/") | ||
| content { | ||
| includeModule("io.gitlab.arturbosch.detekt", "detekt-gradle-plugin") | ||
| } | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Address snapshot repository non-determinism and add removal tracking.
The Sonatype Maven snapshots repository introduces a reproducibility and supply-chain risk:
- Snapshot artifacts are mutable and can change without version bumps.
- Builds on different dates may resolve different binaries, causing non-deterministic behavior.
- The TODO comment lacks a clear removal criterion or issue reference.
Since this PR upgrades to JDK 25, verify whether detekt is now stable in the Gradle plugin portal and can replace this workaround. If it remains necessary, update the TODO to reference a specific issue and define clear removal criteria (e.g., "Remove when detekt X.Y+ is available in gradle plugin portal").
🌐 Web query:
Is detekt stable in the Gradle plugin portal (not snapshot)?
💡 Result:
Yes — detekt is published as stable releases on the Gradle Plugin Portal (not only snapshots). For example, the io.gitlab.arturbosch.detekt plugin shows stable versions (latest listed: 1.23.8). [1][2]
Sources:
- Gradle Plugin Portal — io.gitlab.arturbosch.detekt plugin (shows released versions). [1]
- detekt documentation (Gradle usage / released versions). [2]
Remove unnecessary snapshot repository workaround.
detekt is published as stable releases on the Gradle Plugin Portal (latest: 1.23.8), making the Sonatype Maven snapshots repository workaround unnecessary. This workaround introduces reproducibility and supply-chain risks through mutable snapshot artifacts.
Remove lines 8-15 from buildSrc/build.gradle.kts entirely—the stable detekt plugin is now available directly from the Gradle Plugin Portal.
🤖 Prompt for AI Agents
In buildSrc/build.gradle.kts around lines 8 to 15, the Sonatype Maven snapshots
repository block (the detekt snapshot workaround) is no longer needed because
detekt is available as a stable plugin on the Gradle Plugin Portal; remove lines
8-15 entirely (the maven { url =
"https://central.sonatype.com/repository/maven-snapshots/" ...
includeModule(...) } block) so the build uses the Gradle Plugin Portal only and
avoids mutable snapshot dependencies.
| implementation(libs.kotlin.allopen) | ||
| implementation(libs.kotlin.gradle.plugin) | ||
| // required for kotlin plugin jpa | ||
| implementation(kotlin("reflect", "2.2.21")) | ||
| implementation(kotlin("stdlib-jdk8", "2.2.21")) | ||
| implementation(kotlin("noarg", "2.2.21")) | ||
| implementation(libs.kotlin.reflect) | ||
| implementation(libs.kotlin.stdlib.jdk8) | ||
| implementation(libs.kotlin.noarg) |
There was a problem hiding this comment.
🧩 Analysis chain
CRITICAL: Verify version catalog definitions for Kotlin dependencies.
The code now references version catalog entries (libs.kotlin.*), but a previous review flagged that gradle/libs.versions.toml does not exist. If this file is still missing, the build will fail at dependency resolution time.
Verify that all five Kotlin library entries are properly defined in gradle/libs.versions.toml:
kotlin.allopenkotlin.gradle-pluginkotlin.reflectkotlin.stdlib-jdk8kotlin.noarg
🏁 Script executed:
#!/bin/bash
# Description: Verify that gradle/libs.versions.toml exists and defines all required Kotlin libraries
# Check if gradle/libs.versions.toml exists
if [ ! -f gradle/libs.versions.toml ]; then
echo "ERROR: gradle/libs.versions.toml does not exist"
exit 1
fi
# Search for required Kotlin library definitions
echo "Checking for required Kotlin library definitions:"
rg -c 'kotlin\.(allopen|gradle-plugin|reflect|stdlib-jdk8|noarg)' gradle/libs.versions.tomlLength of output: 47
🏁 Script executed:
#!/bin/bash
# Search for any version catalog files in the repository
echo "Looking for version catalog files (*.versions.toml or libs.versions.toml):"
fd -e "versions.toml" . 2>/dev/null || echo "No *.versions.toml files found"
# Also check for gradle directory structure
echo ""
echo "Gradle directory contents:"
ls -la gradle/ 2>/dev/null || echo "gradle/ directory not found"
# Check if gradle/libs.versions.toml is referenced anywhere else in build files
echo ""
echo "Searching for references to libs.versions.toml or version catalog:"
rg -i "libs\.versions|version.catalog" --type gradle --type kotlin 2>/dev/null | head -20 || echo "No references found"Length of output: 420
csikb
changed the base branch from
main
to
renovate/bellsoft-liberica-runtime-container-25.x
renovate
bot
force-pushed
the
renovate/bellsoft-liberica-runtime-container-25.x
branch
from
43e3b1a to
3619680
Compare
renovate
bot
force-pushed
the
renovate/bellsoft-liberica-runtime-container-25.x
branch
from
3619680 to
169e03d
Compare
renovate
bot
force-pushed
the
renovate/bellsoft-liberica-runtime-container-25.x
branch
from
169e03d to
412a015
Compare
…me-container-25.x' into jdk-25 # Conflicts: # Dockerfile # gradle/libs.versions.toml
|
renovate
bot
force-pushed
the
renovate/bellsoft-liberica-runtime-container-25.x
branch
4 times, most recently
from
1662e9a to
c88bce3
Compare
BREAKING CHANGE
Summary by CodeRabbit
Chores
Tests