Migrate to Gradle 9.5.1 and Java 25#2630
Conversation
- Upgrade Gradle wrapper to 9.5.1 - Replace com.gradle.enterprise with com.gradle.develocity plugin - Upgrade net.researchgate.release to 3.1.0 for Gradle 9 compatibility - Replace all deprecated buildDir references with layout.buildDirectory - Replace Project.exec() calls with ExecOperations injection pattern - Add Java 25 toolchain to all Java subprojects - Upgrade Ballerina Gradle plugin to 4.0.0 (Java 25 + Gradle 9.5.1 compatible) - Update ballerinaLangVersion to 2201.14.0-SNAPSHOT - Update all platform.java21 TOML sections to platform.java25 - Add patchBallerinaScripts task to fix bal binary permissions and remove --sun-misc-unsafe-memory-access=allow flag (removed in Java 25) - Upgrade SpotBugs Gradle plugin to 6.5.1 for Java 25 class file support - Add SpotBugs exclusions for THROWS/AT/USELESS_STRING detectors introduced in SpotBugs 4.9.x (bundled in plugin >= 6.2.0)
Thevakumar-Luheerathan
requested review from
TharmiganK,
daneshk,
lnash94 and
shafreenAnfar
as code owners
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughSwitch platform targets and distribution to Java 25 across Ballerina toml and dependency files, bump build/tool versions, modernize Gradle APIs (layout.buildDirectory, toolchains), replace direct exec calls with injected ExecOperations helpers, add PatchBallerinaScriptsTask, update CI workflow references, and adjust TLS ciphers and related tests. ChangesJava 25 Platform Migration and Gradle Modernization
🎯 4 (Complex) | ⏱️ ~45 minutes
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Pull request overview
This PR upgrades the build to Gradle 9.5.1 and migrates the project to Java 25, updating Gradle build scripts, Ballerina TOML platform sections, and static analysis tooling to remain compatible with the newer toolchain.
Changes:
- Upgraded Gradle wrapper to 9.5.1 and migrated Gradle APIs (
buildDir→layout.buildDirectory, updated task wiring, Develocity plugin migration). - Introduced Java 25 toolchains across Java subprojects and updated Ballerina platform TOMLs from
java21tojava25. - Upgraded tooling versions (SpotBugs 6.5.1, ResearchGate release plugin 3.1.0) and added SpotBugs exclusions for newly surfaced detector categories.
Reviewed changes
Copilot reviewed 27 out of 28 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| settings.gradle | Migrates from Gradle Enterprise plugin to Develocity and updates Build Scan ToS fields. |
| gradle/wrapper/gradle-wrapper.properties | Updates wrapper distribution to Gradle 9.5.1. |
| gradle.properties | Updates Ballerina/Gradle/tooling versions (Ballerina lang/plugin, SpotBugs, release plugin). |
| build.gradle | Adds Java 25 toolchain configuration for Java subprojects; updates build task configuration style. |
| native/build.gradle | Updates SpotBugs reports output configuration to use layout.buildDirectory and new report properties. |
| native/spotbugs-exclude.xml | Adds exclusions for newly surfaced SpotBugs bug codes. |
| compiler-plugin/build.gradle | Updates SpotBugs output configuration and replaces buildDir usage with layout.buildDirectory. |
| compiler-plugin-tests/build.gradle | Updates JaCoCo and SpotBugs output configuration to use layout.buildDirectory. |
| compiler-plugin-tests/spotbugs-exclude.xml | Adds exclusion for SpotBugs bug code newly surfaced by updated engine. |
| build-config/checkstyle/build.gradle | Replaces buildDir usage with layout.buildDirectory for downloaded Checkstyle artifacts. |
| build-config/resources/Ballerina.toml | Updates distribution version and renames platform tables from java21 to java25. |
| build-config/resources/BallerinaTest.toml | Renames platform tables from java21 to java25 for test resources. |
| build-config/resources/BallerinaIntegrationTest.toml | Renames platform dependency tables from java21 to java25. |
| ballerina/build.gradle | Adds script patching task for Java 25; switches git commit exec to ExecOperations; adds mavenLocal() to buildscript repos. |
| ballerina/Ballerina.toml | Updates distribution version and renames platform tables from java21 to java25. |
| ballerina/Dependencies.toml | Updates Ballerina distribution version. |
| integration-tests/build.gradle | Switches git commit exec to ExecOperations; (still contains other exec {} usage). |
| integration-tests/Ballerina.toml | Renames platform dependency tables from java21 to java25. |
| ballerina-tests/build.gradle | Switches git commit exec to ExecOperations; updates tests build scripts (still contains other exec {} usage). |
| ballerina-tests/http2-tests/Ballerina.toml | Renames platform tables from java21 to java25. |
| ballerina-tests/http-service-tests/Ballerina.toml | Renames platform tables from java21 to java25. |
| ballerina-tests/http-security-tests/Ballerina.toml | Renames platform tables from java21 to java25. |
| ballerina-tests/http-resiliency-tests/Ballerina.toml | Renames platform tables from java21 to java25. |
| ballerina-tests/http-misc-tests/Ballerina.toml | Renames platform tables from java21 to java25. |
| ballerina-tests/http-interceptor-tests/Ballerina.toml | Renames platform tables from java21 to java25. |
| ballerina-tests/http-dispatching-tests/Ballerina.toml | Renames platform tables from java21 to java25. |
| ballerina-tests/http-client-tests/Ballerina.toml | Renames platform tables from java21 to java25. |
| ballerina-tests/http-advanced-tests/Ballerina.toml | Renames platform tables from java21 to java25. |
Comments suppressed due to low confidence (2)
integration-tests/build.gradle:99
- This file still uses Gradle's
Project.exec { ... }later (e.g., insideballerinaIntegrationTests.doLast { exec { ... } }). Since this PR is migrating away fromProject.exec()for Gradle 9 compatibility, those remainingexec {}usages should be updated to useExecOperationsas well to avoid deprecation/removal issues.
task commitTomlFiles {
def execHelper = project.objects.newInstance(IntegrationTestsExecHelper)
doLast {
def files = [
"${project.projectDir}/Ballerina.toml",
"${project.projectDir}/Dependencies.toml"
]
execHelper.execOperations.exec {
ignoreExitValue true
if (Os.isFamily(Os.FAMILY_WINDOWS)) {
commandLine(['cmd', '/c', 'git', 'commit', '-m', '[Automated] Update the native jar versions'] + files)
} else {
commandLine(['git', 'commit', '-m', '[Automated] Update the native jar versions'] + files)
}
}
ballerina-tests/build.gradle:121
- Although
commitTomlFilesnow usesExecOperations, this build script still invokes Gradle'sProject.exec { ... }in multiple tasks (e.g.,publishTestCommonPackageToLocal,ballerinaTest, LDAP server tasks). For Gradle 9 migration completeness, these remainingexec {}calls should also be migrated toExecOperations(e.g., via an injected helper/task type) to avoid relying on APIs that are deprecated/removed.
task commitTomlFiles {
def execHelper = project.objects.newInstance(BallerinaTestsExecHelper)
doLast {
def files = "${testCommonPackage}/Ballerina.toml ${testCommonPackage}/Dependencies.toml "
testPackages.each{ testPackage ->
files += "${testPackage}/Ballerina.toml ${testPackage}/Dependencies.toml "
}
execHelper.execOperations.exec {
ignoreExitValue true
if (Os.isFamily(Os.FAMILY_WINDOWS)) {
commandLine 'cmd', '/c', "git commit -m \"[Automated] Update the native jar versions\" ${files}"
} else {
commandLine 'sh', '-c', "git commit -m '[Automated] Update the native jar versions' ${files}"
}
}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Inject JAVA_HOME override immediately after the shebang line | ||
| def shebangIdx = lines.findIndexOf { it.startsWith('#!') } | ||
| if (shebangIdx >= 0) { | ||
| lines.add(shebangIdx + 1, "export JAVA_HOME='${java25Home}'") |
![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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
ballerina-tests/build.gradle (1)
106-123:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftIncomplete Exec migration—remaining
exec { }blocks still useProject.exec(removed in Gradle 9).
commitTomlFilesalready migrated to injectedExecOperations, but the following tasks still use bareexec { ... }:
publishTestCommonPackageToLocal(around lines 180-196)ballerinaTest(around lines 217-238)startLdapServer(around lines 264-273)stopLdapServer(around lines 290-299)Since
Project.exec/Project.javaexecare removed in Gradle 9, these tasks will break; migrate them toExecOperations.execthe same way ascommitTomlFiles.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@ballerina-tests/build.gradle` around lines 106 - 123, The remaining tasks use the removed Project.exec/exec { } API and must be migrated to use the injected ExecOperations like commitTomlFiles does: in each task (publishTestCommonPackageToLocal, ballerinaTest, startLdapServer, stopLdapServer) create or reuse a BallerinaTestsExecHelper instance via project.objects.newInstance(BallerinaTestsExecHelper) and replace the exec { ... } block with execHelper.execOperations.exec { ... }, preserving settings such as commandLine and ignoreExitValue; ensure the helper is instantiated inside the task (e.g., def execHelper = project.objects.newInstance(BallerinaTestsExecHelper)) so the tasks call execHelper.execOperations.exec with the same command strings/args as before.
🧹 Nitpick comments (4)
integration-tests/build.gradle (1)
85-101: ⚖️ Poor tradeoffSame partial migration issue as
ballerina-tests/build.gradle.The
ballerinaIntegrationTeststask at lines 152-161 still uses a bareexec { }block. Apply the sameIntegrationTestsExecHelperpattern for consistency.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@integration-tests/build.gradle` around lines 85 - 101, The ballerinaIntegrationTests task is still using a bare exec { } call—migrate it to use the IntegrationTestsExecHelper pattern (like task commitTomlFiles uses execHelper.exec) to ensure consistent exec behavior; locate the ballerinaIntegrationTests task and replace its exec { ... } blocks with an IntegrationTestsExecHelper instance (project.objects.newInstance(IntegrationTestsExecHelper)) and call execHelper.exec { ... } while preserving the same commandLine, ignoreExitValue, and OS branch logic so behavior remains identical.ballerina/build.gradle (1)
66-80: 💤 Low value
mavenLocal()in buildscript repositories may affect CI reproducibility.Adding
mavenLocal()allows resolving plugins from the local Maven cache, which can mask issues where CI fails but local builds succeed (or vice versa). This is acceptable for development but consider documenting the intent or adding it conditionally.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@ballerina/build.gradle` around lines 66 - 80, The buildscript block currently includes mavenLocal(), which can cause CI reproducibility issues; update the build.gradle buildscript repositories to remove or conditionally include mavenLocal() (e.g., only when a DEV or LOCAL env var is set) and add a brief comment explaining the intent; specifically modify the buildscript -> repositories section (the mavenLocal() call) so CI uses only declared remote repositories and ensure any conditional check reads an environment variable (e.g., processEnv like PACKAGE_USE_LOCAL) or document why mavenLocal() is required.compiler-plugin-tests/spotbugs-exclude.xml (1)
53-56: Consider tracking the suppressed THROWS issues for future resolution.The BugCode-level exclusion suppresses all instances of THROWS bugs (exception handling issues) across the module, including any new violations introduced in future changes. While pragmatic for unblocking the Java 25 migration, consider creating a tracking issue to review and address these pre-existing patterns, then migrate to more targeted class/method-specific exclusions.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@compiler-plugin-tests/spotbugs-exclude.xml` around lines 53 - 56, The current SpotBugs exclusion uses a broad BugCode-level match (<BugCode name="THROWS"/>) which suppresses all THROWS warnings; create a TODO/tracking ticket and replace this global suppression with targeted exclusions (class- or method-level <Match> entries) for the specific pre-existing offenders so future THROWS regressions are not silently ignored—add a comment in spotbugs-exclude.xml referencing the tracking issue ID and then change the <Match> that references BugCode name="THROWS" to one or more <Match> blocks targeting the exact classes or methods that need suppression (or keep the global rule temporarily but document the tracking ticket ID next to <BugCode name="THROWS"/>).native/spotbugs-exclude.xml (1)
220-229: Consider tracking the suppressed bug categories for future resolution.Three BugCode-level exclusions (THROWS, AT, USELESS_STRING) suppress all instances of exception handling, annotation/threading, and string manipulation issues across the native module. These broad exclusions will also mask any new violations introduced in future changes. While pragmatic for unblocking the Java 25 migration, consider:
- Creating a tracking issue to review and remediate these pre-existing patterns
- Migrating to more targeted class/method-specific exclusions once issues are understood
- Establishing a process to periodically review whether these can be narrowed or removed
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@native/spotbugs-exclude.xml` around lines 220 - 229, The SpotBugs exclusions currently blanket three BugCode entries (THROWS, AT, USELESS_STRING) which will hide all related violations; create a tracking issue referencing these BugCode names (THROWS, AT, USELESS_STRING) to triage and document the rationale, add TODO metadata in native/spotbugs-exclude.xml pointing to that issue, and plan a follow-up to replace broad BugCode-level exclusions with targeted <Class> or <Method> matches once individual instances are reviewed and remediated; include a periodic review cadence in the tracking issue so the exclusions can be narrowed or removed over time.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@ballerina/build.gradle`:
- Around line 28-64: The patch task in PatchBallerinaScriptsTask.patch reads
file.text and uses split('\n') which leaves trailing '\r' on Windows CRLF files
and corrupts injected lines; update the line-splitting/normalization so it
handles both LF and CRLF (e.g., use a regex split that matches \r?\n or use a
platform-agnostic readLines()/normalize step) when building the lines list,
ensure injected "export JAVA_HOME..." is inserted without a trailing '\r', and
preserve existing newline semantics when joining back to produce patched before
comparing and writing to file.text.
In `@gradle/wrapper/gradle-wrapper.properties`:
- Line 3: The gradle-wrapper.properties update changed distributionUrl to Gradle
9.5.1 which crosses the 8→9 major boundary; either revert distributionUrl back
to the previous 8.11.1 wrapper or, if you intend to upgrade, run the Gradle 9
migration checklist: update the gradle wrapper (distributionUrl) intentionally,
ensure CI and local builds use Java 17+ for the Gradle daemon, verify embedded
Kotlin/toolchain settings and any Kotlin DSL code, audit Groovy 4
incompatibilities, and test Configuration Cache and any API/behavior removals
across the build; use the distributionUrl value in gradle-wrapper.properties and
the gradle wrapper task to apply the change only after these validations.
---
Outside diff comments:
In `@ballerina-tests/build.gradle`:
- Around line 106-123: The remaining tasks use the removed Project.exec/exec { }
API and must be migrated to use the injected ExecOperations like commitTomlFiles
does: in each task (publishTestCommonPackageToLocal, ballerinaTest,
startLdapServer, stopLdapServer) create or reuse a BallerinaTestsExecHelper
instance via project.objects.newInstance(BallerinaTestsExecHelper) and replace
the exec { ... } block with execHelper.execOperations.exec { ... }, preserving
settings such as commandLine and ignoreExitValue; ensure the helper is
instantiated inside the task (e.g., def execHelper =
project.objects.newInstance(BallerinaTestsExecHelper)) so the tasks call
execHelper.execOperations.exec with the same command strings/args as before.
---
Nitpick comments:
In `@ballerina/build.gradle`:
- Around line 66-80: The buildscript block currently includes mavenLocal(),
which can cause CI reproducibility issues; update the build.gradle buildscript
repositories to remove or conditionally include mavenLocal() (e.g., only when a
DEV or LOCAL env var is set) and add a brief comment explaining the intent;
specifically modify the buildscript -> repositories section (the mavenLocal()
call) so CI uses only declared remote repositories and ensure any conditional
check reads an environment variable (e.g., processEnv like PACKAGE_USE_LOCAL) or
document why mavenLocal() is required.
In `@compiler-plugin-tests/spotbugs-exclude.xml`:
- Around line 53-56: The current SpotBugs exclusion uses a broad BugCode-level
match (<BugCode name="THROWS"/>) which suppresses all THROWS warnings; create a
TODO/tracking ticket and replace this global suppression with targeted
exclusions (class- or method-level <Match> entries) for the specific
pre-existing offenders so future THROWS regressions are not silently ignored—add
a comment in spotbugs-exclude.xml referencing the tracking issue ID and then
change the <Match> that references BugCode name="THROWS" to one or more <Match>
blocks targeting the exact classes or methods that need suppression (or keep the
global rule temporarily but document the tracking ticket ID next to <BugCode
name="THROWS"/>).
In `@integration-tests/build.gradle`:
- Around line 85-101: The ballerinaIntegrationTests task is still using a bare
exec { } call—migrate it to use the IntegrationTestsExecHelper pattern (like
task commitTomlFiles uses execHelper.exec) to ensure consistent exec behavior;
locate the ballerinaIntegrationTests task and replace its exec { ... } blocks
with an IntegrationTestsExecHelper instance
(project.objects.newInstance(IntegrationTestsExecHelper)) and call
execHelper.exec { ... } while preserving the same commandLine, ignoreExitValue,
and OS branch logic so behavior remains identical.
In `@native/spotbugs-exclude.xml`:
- Around line 220-229: The SpotBugs exclusions currently blanket three BugCode
entries (THROWS, AT, USELESS_STRING) which will hide all related violations;
create a tracking issue referencing these BugCode names (THROWS, AT,
USELESS_STRING) to triage and document the rationale, add TODO metadata in
native/spotbugs-exclude.xml pointing to that issue, and plan a follow-up to
replace broad BugCode-level exclusions with targeted <Class> or <Method> matches
once individual instances are reviewed and remediated; include a periodic review
cadence in the tracking issue so the exclusions can be narrowed or removed over
time.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1453f984-b756-4e86-aef9-5fa328597f5f
📒 Files selected for processing (28)
ballerina-tests/build.gradleballerina-tests/http-advanced-tests/Ballerina.tomlballerina-tests/http-client-tests/Ballerina.tomlballerina-tests/http-dispatching-tests/Ballerina.tomlballerina-tests/http-interceptor-tests/Ballerina.tomlballerina-tests/http-misc-tests/Ballerina.tomlballerina-tests/http-resiliency-tests/Ballerina.tomlballerina-tests/http-security-tests/Ballerina.tomlballerina-tests/http-service-tests/Ballerina.tomlballerina-tests/http2-tests/Ballerina.tomlballerina/Ballerina.tomlballerina/Dependencies.tomlballerina/build.gradlebuild-config/checkstyle/build.gradlebuild-config/resources/Ballerina.tomlbuild-config/resources/BallerinaIntegrationTest.tomlbuild-config/resources/BallerinaTest.tomlbuild.gradlecompiler-plugin-tests/build.gradlecompiler-plugin-tests/spotbugs-exclude.xmlcompiler-plugin/build.gradlegradle.propertiesgradle/wrapper/gradle-wrapper.propertiesintegration-tests/Ballerina.tomlintegration-tests/build.gradlenative/build.gradlenative/spotbugs-exclude.xmlsettings.gradle
| abstract class PatchBallerinaScriptsTask extends DefaultTask { | ||
| @Inject abstract JavaToolchainService getJavaToolchainService() | ||
|
|
||
| @TaskAction | ||
| void patch() { | ||
| def launcher = javaToolchainService.launcherFor { spec -> | ||
| spec.languageVersion.set(JavaLanguageVersion.of(25)) | ||
| }.get() | ||
| def java25Home = launcher.executablePath.asFile.parentFile.parentFile.absolutePath | ||
|
|
||
| def binDirs = [ | ||
| project.layout.buildDirectory.dir("jballerina-tools-${project.ballerinaLangVersion}/bin").get().asFile, | ||
| new File("${project.rootDir}/target/ballerina-runtime/bin") | ||
| ] | ||
| binDirs.each { binDir -> | ||
| if (binDir.exists()) { | ||
| binDir.eachFile { file -> | ||
| file.setExecutable(true) | ||
| if (!file.name.endsWith('.bat') && !file.name.endsWith('.cmd')) { | ||
| def original = file.text | ||
| def lines = original.split('\n').toList() | ||
| lines = lines.findAll { !it.contains('--sun-misc-unsafe-memory-access=allow') } | ||
| // Inject JAVA_HOME override immediately after the shebang line | ||
| def shebangIdx = lines.findIndexOf { it.startsWith('#!') } | ||
| if (shebangIdx >= 0) { | ||
| lines.add(shebangIdx + 1, "export JAVA_HOME='${java25Home}'") | ||
| } | ||
| def patched = lines.join('\n') + '\n' | ||
| if (patched != original) { | ||
| file.text = patched | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
CRLF line endings not handled in script patching.
Line 48 uses split('\n') which doesn't strip \r from lines if scripts have Windows-style CRLF endings. This would result in malformed scripts with trailing carriage returns.
Consider using a regex that handles both:
🛡️ Proposed fix for cross-platform line ending handling
- def lines = original.split('\n').toList()
+ def lines = original.split(/\r?\n/).toList()🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@ballerina/build.gradle` around lines 28 - 64, The patch task in
PatchBallerinaScriptsTask.patch reads file.text and uses split('\n') which
leaves trailing '\r' on Windows CRLF files and corrupts injected lines; update
the line-splitting/normalization so it handles both LF and CRLF (e.g., use a
regex split that matches \r?\n or use a platform-agnostic readLines()/normalize
step) when building the lines list, ensure injected "export JAVA_HOME..." is
inserted without a trailing '\r', and preserve existing newline semantics when
joining back to produce patched before comparing and writing to file.text.
| distributionBase=GRADLE_USER_HOME | ||
| distributionPath=wrapper/dists | ||
| distributionUrl=https\://services.gradle.org/distributions/gradle-8.11.1-bin.zip | ||
| distributionUrl=https\://services.gradle.org/distributions/gradle-9.5.1-bin.zip |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Has Gradle 9.5.1 been released and is it stable?
💡 Result:
Yes—Gradle 9.5.1 has been released (tag v9.5.1 on GitHub, published 2026-05-12) [1] and it’s available for download from Gradle’s distribution site (bin/all/docs/src artifacts dated 12-May-2026) [2]. On whether it’s stable: Gradle 9.5.1 is a patch release (the first patch release for the 9.5.0 line) [3] and the official release notes explicitly recommend upgrading to 9.5.1 [3]. The release notes also describe it as a fixes/improvements release (“issues were resolved”) rather than a major-version change [3].
Citations:
- 1: https://github.com/gradle/gradle/releases/tag/v9.5.1
- 2: https://services.gradle.org/distributions
- 3: https://docs.gradle.org/current/release-notes.html
🌐 Web query:
Gradle 9 migration guide breaking changes from Gradle 8 to Gradle 9
💡 Result:
Gradle 9 migration (Gradle 8 → Gradle 9): key breaking changes to check 1) Minimum Java requirement (Gradle daemon) Gradle 9.0.0 requires running the Gradle daemon on JVM 17+ (breaking vs earlier Gradle 8.x that supported JVM 8+). [1] 2) Kotlin DSL / embedded Kotlin upgrade The Kotlin DSL is upgraded to the embedded Kotlin 2.2.x runtime and uses Kotlin language version 2.2 across the toolchain (a shift from Gradle 8.x’s embedded Kotlin 2.0 with Kotlin language version 1.8 for compatibility). [1] 3) Groovy upgrade to Groovy 4 Gradle 9.0.0 upgrades Groovy from 3.0.x to 4.0.27, which includes many breaking language-level changes (e.g., removal of legacy packages, module structure changes, parser rewrite, bytecode output changes). [1] 4) Configuration Cache / API removals theme Gradle 9 removed many previously deprecated APIs and behaviors that were incompatible with Configuration Cache, replacing them with alternatives compatible with it. [2] 5) Kotlin/JSpecify + stricter nullability in Gradle API (binary/signature impact) Starting with Gradle 9, the Gradle API is annotated using JSpecify instead of the earlier JSR-305-based approach; Gradle 9 release notes call out stricter nullability handling and potential binary API changes due to Kotlin 2.1 + JSpecify. [3] 6) Plugin/build behavior changes called out in the 9.0.0 upgrade guide The Gradle 9.0.0 upgrade guide specifically highlights multiple categories of breaking changes including: - Plugin changes (including cases where test tasks may no longer execute expected tests / test failures when no tests are discovered). [4] - Build/cache behavior changes, such as “stale outputs outside the build directory are no longer deleted.” [4] - API/feature removals and “Removal of conventions.” [1] Where to look (most authoritative lists) - Primary migration guide for Gradle 8.14.x → Gradle 9.0.0: https://docs.gradle.org/current/userguide/upgrading_major_version_9.html [1] - Release notes for Gradle 9.0.0 (additional context/notes): https://docs.gradle.org/9.0.0/release-notes.html [3] - “What’s new in Gradle 9” overview (themes like Configuration Cache compatibility): https://gradle.org/whats-new/gradle-9/ [2] If you share which Gradle 8.x patchlevel you’re on (e.g., 8.5, 8.14.2, etc.) and whether you use Groovy or Kotlin DSL (plus any custom plugins), I can narrow this to the exact breaking sections most likely to affect your build.
Citations:
- 1: https://docs.gradle.org/current/userguide/upgrading_major_version_9.html
- 2: https://gradle.org/whats-new/gradle-9/
- 3: https://docs.gradle.org/9.0.0/release-notes.html
- 4: https://docs.gradle.org/9.4.0/userguide/upgrading_major_version_9.html
Gradle wrapper: Gradle 9.5.1 is released (patch); still review 8.11.1 → 9.x breaking changes
distributionUrl=https\://services.gradle.org/distributions/gradle-9.5.1-bin.zip
Gradle 9.5.1 is available and is published as a fixes/improvements (patch) release with release notes recommending the upgrade. Since this still jumps across the Gradle 9 major line from 8.11.1, review the Gradle 9 migration guide for breaking changes to your build scripts, especially:
- Java 17+ requirement for the Gradle daemon
- embedded Kotlin + toolchain upgrades
- Groovy 4 language changes
- API/behavior removals tied to Configuration Cache compatibility
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@gradle/wrapper/gradle-wrapper.properties` at line 3, The
gradle-wrapper.properties update changed distributionUrl to Gradle 9.5.1 which
crosses the 8→9 major boundary; either revert distributionUrl back to the
previous 8.11.1 wrapper or, if you intend to upgrade, run the Gradle 9 migration
checklist: update the gradle wrapper (distributionUrl) intentionally, ensure CI
and local builds use Java 17+ for the Gradle daemon, verify embedded
Kotlin/toolchain settings and any Kotlin DSL code, audit Groovy 4
incompatibilities, and test Configuration Cache and any API/behavior removals
across the build; use the distributionUrl value in gradle-wrapper.properties and
the gradle wrapper task to apply the change only after these validations.
Update graalvm workflow to call the java-25-migration branch of ballerina-library template instead of @main, so GraalVM checks use Java 25 matching the module's compilation target.
Update pull-request workflow to call the java-25-migration branch of ballerina-library template instead of @main, so PR builds use Java 25. Also add concurrency group to cancel duplicate runs.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-with-bal-test-graalvm.yml:
- Line 43: Update the reusable workflow reference on the "uses:" line that
currently ends with "`@java-25-migration`" to a fixed commit SHA (replace
"`@java-25-migration`" with "@<full-commit-sha>") so CI is deterministic; locate
the "uses:
ballerina-platform/ballerina-library/.github/workflows/build-with-bal-test-graalvm-template.yml@java-25-migration"
entry in build-with-bal-test-graalvm.yml and swap the mutable ref for the full
commit SHA of the target repo/tag, commit the change, and verify the workflow
runs.
In @.github/workflows/pull-request.yml:
- Around line 13-14: The reusable workflow invocation currently uses a mutable
branch ref and forwards all secrets with "secrets: inherit", which is unsafe;
change the "uses:
ballerina-platform/ballerina-library/.github/workflows/pull-request-build-template.yml@java-25-migration"
to a specific immutable commit SHA (replace the `@java-25-migration` ref with the
exact commit SHA) and remove "secrets: inherit", instead explicitly pass only
the needed secrets (e.g., "secrets: MY_SECRET: ${{ secrets.MY_SECRET }}" for
each required secret) so that you pin the workflow version and limit secret
exposure.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 511dbdea-3bb3-4603-b5fd-4b7580419fbc
📒 Files selected for processing (2)
.github/workflows/build-with-bal-test-graalvm.yml.github/workflows/pull-request.yml
| name: Run StdLib Workflow | ||
| if: ${{ github.event_name != 'schedule' || (github.event_name == 'schedule' && github.repository_owner == 'ballerina-platform') }} | ||
| uses: ballerina-platform/ballerina-library/.github/workflows/build-with-bal-test-graalvm-template.yml@main | ||
| uses: ballerina-platform/ballerina-library/.github/workflows/build-with-bal-test-graalvm-template.yml@java-25-migration |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify mutable workflow refs in repo workflows.
rg -nP '^\s*uses:\s*[^#\n]+@((main|master|[A-Za-z0-9._/-]+))\s*$' .github/workflows
# Expected: this line should be gone once pinned to a 40-char SHA.Repository: ballerina-platform/module-ballerina-http
Length of output: 2936
Pin reusable workflow reference in build-with-bal-test-graalvm.yml to a commit SHA
./.github/workflows/build-with-bal-test-graalvm.yml line 43 references a reusable workflow with the mutable ref @java-25-migration—use the full commit SHA instead to keep CI behavior deterministic.
🔒 Suggested fix
- uses: ballerina-platform/ballerina-library/.github/workflows/build-with-bal-test-graalvm-template.yml@java-25-migration
+ uses: ballerina-platform/ballerina-library/.github/workflows/build-with-bal-test-graalvm-template.yml@<full_commit_sha>🧰 Tools
🪛 zizmor (1.25.2)
[error] 43-43: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build-with-bal-test-graalvm.yml at line 43, Update the
reusable workflow reference on the "uses:" line that currently ends with
"`@java-25-migration`" to a fixed commit SHA (replace "`@java-25-migration`" with
"@<full-commit-sha>") so CI is deterministic; locate the "uses:
ballerina-platform/ballerina-library/.github/workflows/build-with-bal-test-graalvm-template.yml@java-25-migration"
entry in build-with-bal-test-graalvm.yml and swap the mutable ref for the full
commit SHA of the target repo/tag, commit the change, and verify the workflow
runs.
| uses: ballerina-platform/ballerina-library/.github/workflows/pull-request-build-template.yml@java-25-migration | ||
| secrets: inherit |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find reusable workflow calls that are mutable and/or inherit all secrets.
rg -nP '^\s*uses:\s*[^#\n]+@([A-Za-z0-9._/-]+)\s*$|^\s*secrets:\s*inherit\s*$' .github/workflows
# Expected after fix:
# - `uses:` for external/reusable workflows pinned to full SHAs
# - no unconditional `secrets: inherit` unless explicitly justifiedRepository: ballerina-platform/module-ballerina-http
Length of output: 3349
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/pull-request.yml"
echo "== File: $FILE =="
nl -ba "$FILE" | sed -n '1,80p'Repository: ballerina-platform/module-ballerina-http
Length of output: 192
🌐 Web query:
GitHub Actions reusable workflow security pin commit SHA secrets: inherit
💡 Result:
In a GitHub Actions workflow that calls a reusable workflow, secrets: inherit is supported and it passes the caller workflow’s secrets to the directly called reusable workflow. Specifically, reusable workflow docs show secrets: inherit in a job that uses another workflow via uses: owner/repo/.github/workflows/<file>@<ref>, and they note that you can reference inherited secrets even when they’re not explicitly defined under the reusable workflow’s on: workflow_call secret list [1]. The workflow syntax reference also describes passing secrets and the jobs.<job_id>.secrets.inherit form for passing all calling-workflow secrets into the directly called workflow [2]. For security pinning: when referencing reusable workflows (and third-party actions), you should pin the uses: reference to a specific immutable identifier. GitHub’s “Secure use” guidance says using a full-length commit SHA is the only way to treat an action as an immutable release, and pinning to a full-length commit SHA mitigates the risk of a backdoor being added to the action’s repository [3]. The reusable-workflow docs explicitly state that the {ref} portion can be a SHA, release tag, or branch name, and that using the commit SHA is the safest option for stability and security [1]. So the best practice pattern is: - Pin the reusable workflow uses: ref to a full-length commit SHA (not a branch like main, not a moving tag) [1][3]. - If you need secrets from the caller, use secrets: inherit only when the called workflow is trusted and you intentionally want to pass all caller secrets through the workflow chain (note secrets are only passed to the directly called workflow, not implicitly further) [2][4]. Example (caller workflow job that pins reusable workflow and inherits secrets): - uses: ORG/REPO/.github/workflows/reusable.yml@<full-length-commit-sha> - secrets: inherit [1][2]. Security note on scope: GitHub docs clarify that in a workflow chain A > B > C, workflow C will only receive secrets from A if A passes secrets to B, and then B passes them to C; secrets: inherit does not automatically propagate beyond the directly called workflow [4].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md
- 3: https://github.com/github/docs/blob/main/content/actions/reference/security/secure-use.md
- 4: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE=".github/workflows/pull-request.yml"
echo "== $FILE (lines 8-22) =="
awk 'NR>=8 && NR<=22 {printf "%d:%s\n", NR, $0}' "$FILE"Repository: ballerina-platform/module-ballerina-http
Length of output: 412
🌐 Web query:
ballerina-platform/ballerina-library pull-request-build-template.yml java-25-migration secrets inherit
💡 Result:
I couldn’t locate the specific file path you mentioned (ballerina-platform/ballerina-library pull-request-build-template.yml java-25-migration secrets inherit). What I can confirm from authoritative sources is the following relevant parts: 1) How secrets: inherit works for reusable GitHub workflows - In GitHub Actions, you can call a reusable workflow and pass secrets implicitly using secrets: inherit. The called (reusable) workflow can then reference those secrets even if they aren’t explicitly defined in the called workflow’s on inputs/keys. [1] - You can also pass all calling workflow secrets to a directly called workflow with jobs.<job_id>.secrets.inherit. [1] 2) Example showing secrets: inherit used with a Ballerina-library reusable workflow - In ballerina-platform/module-ballerinax-azure.ai.search, the repository’s .github/workflows/pull-request.yml calls a reusable workflow in ballerina-platform/ballerina-library and sets secrets: inherit. [2] 3) Evidence around “Java 25 migration” context (Ballerina-related) - There is an open issue about “Getting warnings when running in Java 25” in ballerina-platform/ballerina-lang, indicating Java 25-specific runtime warnings are a consideration in the Ballerina ecosystem. [3] - A Java 25 migration guide exists (OpenRewrite) but it’s about upgrading Java codebases broadly; it doesn’t directly confirm any specific pull-request-build-template.yml behavior in ballerina-library. [4] If you share the exact repo URL (or paste the relevant portion of the pull-request-build-template.yml and/or the java-25-migration job block), I can verify precisely whether and where secrets: inherit is used and how the Java 25 migration is wired in that template.
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://github.com/ballerina-platform/module-ballerinax-azure.ai.search/blob/460eabe621c6d70e7fe3c785d9289c9d34128431/.github/workflows/pull-request.yml
- 3: [Improvement]: Getting warnings when running in Java 25 ballerina-lang#44534
- 4: https://docs.openrewrite.org/running-recipes/popular-recipe-guides/migrate-to-java-25
Pin the reusable workflow ref to an immutable commit SHA and avoid secrets: inherit
.github/workflows/pull-request.yml calls ballerina-platform/ballerina-library/.github/workflows/pull-request-build-template.yml@java-25-migration and uses secrets: inherit, forwarding all caller secrets to the reusable workflow.
uses: ballerina-platform/ballerina-library/.github/workflows/pull-request-build-template.yml@java-25-migration
secrets: inherit
🔐 Suggested hardening
- uses: ballerina-platform/ballerina-library/.github/workflows/pull-request-build-template.yml@java-25-migration
- secrets: inherit
+ uses: ballerina-platform/ballerina-library/.github/workflows/pull-request-build-template.yml@<full_commit_sha>
+ secrets:
+ REQUIRED_SECRET_NAME: ${{ secrets.REQUIRED_SECRET_NAME }}🧰 Tools
🪛 zizmor (1.25.2)
[error] 13-13: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[warning] 13-13: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow
(secrets-inherit)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/pull-request.yml around lines 13 - 14, The reusable
workflow invocation currently uses a mutable branch ref and forwards all secrets
with "secrets: inherit", which is unsafe; change the "uses:
ballerina-platform/ballerina-library/.github/workflows/pull-request-build-template.yml@java-25-migration"
to a specific immutable commit SHA (replace the `@java-25-migration` ref with the
exact commit SHA) and remove "secrets: inherit", instead explicitly pass only
the needed secrets (e.g., "secrets: MY_SECRET: ${{ secrets.MY_SECRET }}" for
each required secret) so that you pin the workflow version and limit secret
exposure.
…ests
- Bump jacocoVersion from 0.8.10 to 0.8.13 to support Java 25 class file version (major version 69)
- Replace bare exec {} with project.exec {} in DefaultTask doLast blocks (startLdapServer, stopLdapServer, publishTestCommonPackageToLocal, ballerinaTest) since Gradle 9 removed the implicit exec() method from DefaultTask
Replace all project.exec { } closure calls with ExecOperations injection
pattern (BallerinaTestsExecHelper) in publishTestCommonPackageToLocal,
ballerinaTest, startLdapServer, and stopLdapServer tasks.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
gradle.properties (2)
30-33:⚠️ Potential issue | 🟠 Major | ⚡ Quick winVerify Java 25 / Gradle 9.5.1 compatibility for SpotBugs 6.5.1 and researchgate release 3.1.0
githubSpotbugsVersion=6.5.1by itself doesn’t provide evidence for Java 25 / ASM 9.7 support; the Java 25 handling depends on the actual SpotBugs version you run (configured via the SpotBugs toolVersion/spotbugs config). Resolve the final SpotBugs + ASM versions from the Gradle dependency graph.researchgateReleaseVersion=3.1.0documentation only claims “Gradle 6.0 and beyond” and doesn’t explicitly mention Gradle 9.5.1; validate the upgrade path for 9.5.1 during the migration.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@gradle.properties` around lines 30 - 33, Verify compatibility for Java 25 / Gradle 9.5.1 by resolving the actual SpotBugs runtime and ASM versions pulled in by the project: inspect the Gradle dependency graph (for example via ./gradlew dependencies or dependencyInsight) to confirm that the effective SpotBugs toolVersion and ASM are compatible with Java 25 rather than relying solely on githubSpotbugsVersion=6.5.1, and update the SpotBugs toolVersion/spotbugs config or bump githubSpotbugsVersion accordingly if ASM < 9.7 is selected; similarly validate researchgateReleaseVersion=3.1.0 works with Gradle 9.5.1 by testing the release plugin tasks with Gradle 9.5.1 and, if incompatible, pick a newer compatible release plugin version or add compatibility notes in the migration docs.
19-19:⚠️ Potential issue | 🟠 Major | ⚡ Quick winConfirm
io.ballerina:plugin-gradle:4.0.0exists and that Java 25 support is actually provided
gradle.propertiessetsballerinaGradlePluginVersion=4.0.0, andballerina/build.gradleresolvesio.ballerina:plugin-gradle:${project.ballerinaGradlePluginVersion}.- No public evidence/release/tag found for
plugin-gradle4.0.0 (repo latest appears to bev0.9.1), so this bump risks an unresolved dependency.- Java 25 support generally depends on using Gradle 9.1.0+ (toolchains/JVM); there’s no source tying
plugin-gradle4.0.0 specifically to Java 25—please confirm the repo’s Gradle/JDK/toolchain matrix and the documented reason this exact version is required.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@gradle.properties` at line 19, The property ballerinaGradlePluginVersion=4.0.0 may point to a non‑existent artifact and you must confirm Java 25 support; verify that the Maven artifact groupId io.ballerina artifactId plugin-gradle version 4.0.0 is published (or pick the latest published tag, e.g., v0.9.1) and update the ballerinaGradlePluginVersion accordingly, or revert to the known-good published version used in ballerina/build.gradle; additionally, document or assert in the build config which Gradle and JDK/toolchain versions support Java 25 (e.g., require Gradle 9.1.0+ and appropriate toolchain settings) and include that rationale next to the ballerinaGradlePluginVersion so future readers know why a specific plugin version is required.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@gradle.properties`:
- Line 4: The ballerinaLangVersion in gradle.properties is set to a timestamped
snapshot which may not be available in Maven Central and may lack Java 25
support; update the ballerinaLangVersion property to a published,
repository-available Ballerina release (or the specific release that documents
Java 25 support) instead of the snapshot (refer to the ballerinaLangVersion key
in gradle.properties), and verify the chosen version exists in Maven
Central/Ballerina staging before committing.
- Line 25: The jacocoVersion property is set to 0.8.13 which lacks official Java
25 support; update the jacocoVersion property value to 0.8.14 or later in
gradle.properties (the jacocoVersion variable) so the build uses a JaCoCo
release with official Java 25 support; after changing jacocoVersion, run your
Gradle build/tests to verify instrumentation and adjust any CI JDK matrix to use
a compatible JaCoCo version if necessary.
---
Outside diff comments:
In `@gradle.properties`:
- Around line 30-33: Verify compatibility for Java 25 / Gradle 9.5.1 by
resolving the actual SpotBugs runtime and ASM versions pulled in by the project:
inspect the Gradle dependency graph (for example via ./gradlew dependencies or
dependencyInsight) to confirm that the effective SpotBugs toolVersion and ASM
are compatible with Java 25 rather than relying solely on
githubSpotbugsVersion=6.5.1, and update the SpotBugs toolVersion/spotbugs config
or bump githubSpotbugsVersion accordingly if ASM < 9.7 is selected; similarly
validate researchgateReleaseVersion=3.1.0 works with Gradle 9.5.1 by testing the
release plugin tasks with Gradle 9.5.1 and, if incompatible, pick a newer
compatible release plugin version or add compatibility notes in the migration
docs.
- Line 19: The property ballerinaGradlePluginVersion=4.0.0 may point to a
non‑existent artifact and you must confirm Java 25 support; verify that the
Maven artifact groupId io.ballerina artifactId plugin-gradle version 4.0.0 is
published (or pick the latest published tag, e.g., v0.9.1) and update the
ballerinaGradlePluginVersion accordingly, or revert to the known-good published
version used in ballerina/build.gradle; additionally, document or assert in the
build config which Gradle and JDK/toolchain versions support Java 25 (e.g.,
require Gradle 9.1.0+ and appropriate toolchain settings) and include that
rationale next to the ballerinaGradlePluginVersion so future readers know why a
specific plugin version is required.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d60f80fb-0cdd-4073-8fc4-9f91d6e49342
📒 Files selected for processing (2)
ballerina-tests/build.gradlegradle.properties
| group=io.ballerina.stdlib | ||
| version=2.17.0-SNAPSHOT | ||
| ballerinaLangVersion=2201.13.3 | ||
| ballerinaLangVersion=2201.14.0-20260527-050400-74f7e6bf |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify that the Ballerina snapshot version exists in Maven repositories
# Check Maven Central
echo "Checking Maven Central..."
curl -s "https://repo1.maven.org/maven2/org/ballerinalang/jballerina-tools/2201.14.0-20260527-050400-74f7e6bf/" | grep -q "jballerina-tools" && echo "✓ Found in Maven Central" || echo "✗ Not found in Maven Central"
# Check Ballerina's staging repository
echo "Checking Ballerina staging repository..."
curl -s "https://maven.pkg.github.com/ballerina-platform/ballerina-lang/org/ballerinalang/jballerina-tools/2201.14.0-20260527-050400-74f7e6bf/" | grep -q "jballerina-tools" && echo "✓ Found in staging" || echo "✗ Not found in staging"
# List recent versions from Maven Central for comparison
echo -e "\nRecent versions available:"
curl -s "https://repo1.maven.org/maven2/org/ballerinalang/jballerina-tools/" | grep -oP '2201\.\d+\.\d+(-\d+)?' | sort -V | tail -10Repository: ballerina-platform/module-ballerina-http
Length of output: 231
🌐 Web query:
Does Ballerina 2201.14.0 support Java 25 runtime?
💡 Result:
No definitive evidence found that Ballerina 2201.14.0 (Swan Lake) explicitly supports “Java 25 runtime.” What the official Ballerina sources do show is: 1) Ballerina runtime support jumped to Java 21 in Swan Lake Update 11 (2201.11.0), and the runtime is described as “now supports Java 21”.[1][2] 2) There are issues showing Ballerina running on newer Java (e.g., Java 25) with runtime warnings, indicating it may run but is not presented as an officially supported target in the cited official release notes.[3] Therefore, based on cited official documentation, Ballerina 2201.14.0 should be expected to support up through Java 21 (as the latest explicitly documented LTS support in Swan Lake Update 11). Any Java 25 compatibility is not confirmed as “supported” for 2201.14.0 in the sources retrieved; only warnings are evidenced for Java 25 in later Ballerina versions.[1][3]
Citations:
- 1: https://blog.ballerina.io/posts/2025-02-11-announcing-ballerina-2201.11.0-swan-lake-update-11
- 2: https://github.com/ballerina-platform/ballerina-dev-website/blob/master/downloads/swan-lake-release-notes/swan-lake-2201.11.0/RELEASE_NOTE.md
- 3: [Improvement]: Getting warnings when running in Java 25 ballerina-lang#44534
Pin ballerinaLangVersion to a published release; current snapshot risks build breakage and lacks Java 25 support evidence
gradle.properties: ballerinaLangVersion=2201.14.0-20260527-050400-74f7e6bf is a timestamped snapshot. The expected org/ballerinalang/jballerina-tools/<version> path is not present in the checked Maven Central or Ballerina staging listings, so CI/builds may fail when resolving the dependency.
Also, Java 25 support is not documented as supported for the 2201.14.x line (Swan Lake Update 11 release notes explicitly state Java 21 support as the latest documented target), so using Java 25 may be unsupported.
- Recommend switching to a published, repository-available Ballerina version (or the exact version that is documented to support Java 25), rather than an unverified snapshot.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@gradle.properties` at line 4, The ballerinaLangVersion in gradle.properties
is set to a timestamped snapshot which may not be available in Maven Central and
may lack Java 25 support; update the ballerinaLangVersion property to a
published, repository-available Ballerina release (or the specific release that
documents Java 25 support) instead of the snapshot (refer to the
ballerinaLangVersion key in gradle.properties), and verify the chosen version
exists in Maven Central/Ballerina staging before committing.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
ballerina-tests/http-security-tests/tests/ssl_cipher_strength_test.bal (1)
62-62: 💤 Low valueConsider renaming
weakCipherConfigfor clarity.The cipher suite was updated to
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, which is cryptographically strong (256-bit AES, GCM mode, ECDHE key exchange). The "weak" label appears to refer to cipher incompatibility for the negative test case rather than cryptographic weakness. While this works correctly for the test (client cipher at line 90 won't match, triggering the expected handshake failure), the naming may confuse future maintainers.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@ballerina-tests/http-security-tests/tests/ssl_cipher_strength_test.bal` at line 62, Rename the misleading variable weakCipherConfig to a clearer name like incompatibleCipherConfig or nonMatchingCipherConfig to reflect that the test uses a crypto-strong but non-matching cipher suite; update the declaration (weakCipherConfig) and all references/usages (e.g., the client config that expects a mismatch/handshake failure) in ssl_cipher_strength_test.bal so the new identifier is used consistently throughout the test.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@ballerina-tests/http-security-tests/tests/ssl_cipher_strength_test.bal`:
- Line 62: Rename the misleading variable weakCipherConfig to a clearer name
like incompatibleCipherConfig or nonMatchingCipherConfig to reflect that the
test uses a crypto-strong but non-matching cipher suite; update the declaration
(weakCipherConfig) and all references/usages (e.g., the client config that
expects a mismatch/handshake failure) in ssl_cipher_strength_test.bal so the new
identifier is used consistently throughout the test.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: bf351313-16c4-4747-82cf-dd7e6439552d
📒 Files selected for processing (11)
ballerina-tests/http-advanced-tests/Dependencies.tomlballerina-tests/http-security-tests/tests/ssl_cipher_strength_test.balballerina-tests/http-test-common/Dependencies.tomlballerina-tests/http2-tests/Dependencies.tomlballerina/Dependencies.tomlnative/src/test/java/io/ballerina/stdlib/http/transport/certificatevalidation/Utils.javanative/src/test/java/io/ballerina/stdlib/http/transport/http2/frameleveltests/client/Http2TcpServerGoAway100ContinueScenarioTest.javanative/src/test/java/io/ballerina/stdlib/http/transport/https/CipherSuitesTest.javanative/src/test/java/io/ballerina/stdlib/http/transport/https/CipherSuiteswithCertsTest.javanative/src/test/java/io/ballerina/stdlib/http/transport/util/Http2Util.javanative/src/test/java/io/ballerina/stdlib/http/transport/util/server/HttpsServer.java
✅ Files skipped from review due to trivial changes (4)
- native/src/test/java/io/ballerina/stdlib/http/transport/util/Http2Util.java
- ballerina-tests/http-test-common/Dependencies.toml
- ballerina-tests/http2-tests/Dependencies.toml
- ballerina-tests/http-advanced-tests/Dependencies.toml
Java 25 changed the JSSE error message format to include the alert name in parentheses (e.g. "(handshake_failure) Received fatal alert: ..."), breaking the exact assertEquals check in ssl_cipher_strength_test.bal. Also, on Windows Java 25, a TLSv1.3 client connecting to a TLSv1.2-only server produces a different error message that doesn't contain "SSL connection failed", breaking testSslProtocolConflict in http2_ssl_protocol_test.bal. Replace exact string equality with flexible strings:includes checks that accept the known error message variants across platforms and Java versions.
Thevakumar-Luheerathan
force-pushed
the
java-25-migration
branch
from
929343b to
f67c428
Compare
|
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your project check has failed because the head coverage (79.32%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## master #2630 +/- ##
============================================
+ Coverage 79.21% 79.32% +0.11%
- Complexity 0 915 +915
============================================
Files 376 441 +65
Lines 21636 24556 +2920
Branches 3382 3929 +547
============================================
+ Hits 17138 19480 +2342
- Misses 3547 3876 +329
- Partials 951 1200 +249 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Applied fixes: A1+B1+B4, B3, B5+C1 - Make patchBallerinaScripts idempotent and add task @input properties (A1, B1) - Use token-level JVM flag removal instead of line filter (B4) - Remove mavenLocal() from plugin repositories (A4) - Scope SpotBugs suppressions to module packages (A5) - Add Gradle wrapper integrity checksum (B3) - Wire jacocoVersion property to JaCoCo toolVersion (B5) - Bump JaCoCo to 0.8.14 for stable Java 25 support (C1)
|
Summary
buildDirAPI withlayout.buildDirectory; replaceProject.exec()withExecOperationsinjection; migrate fromcom.gradle.enterprisetocom.gradle.develocityplugin; upgradenet.researchgate.releaseto 3.1.0ballerinaLangVersionto2201.14.0-SNAPSHOT; update all[platform.java21]TOML sections to[platform.java25]; addpatchBallerinaScriptstask to remove the--sun-misc-unsafe-memory-access=allowJVM flag (removed in Java 25) from the extractedbalbinary after unpackTHROWS,AT, andUSELESS_STRINGdetectors introduced in SpotBugs 4.9.x — these are pre-existing code patterns now surfaced by the updated analysis engineTest plan
./gradlew clean build -x testpasses green across all subprojects.balaartifact is created asballerina-http-java25-2.17.0.balahttp-nativeandhttp-compiler-plugin-tests./gradlew build) in CIThis PR migrates the build and runtime toolchain to Gradle 9.5.1 and Java 25, updates related plugins and CI references, modernizes Gradle usage, and applies packaging and static-analysis adjustments to ensure compatibility with the new toolchain.
Build system and tooling
Java and Ballerina platform migration
API modernization and task wiring
Packaging changes
Dependency and plugin updates
Static analysis adjustments
Test plan
Impact: modernizes build and runtime targets for improved compatibility and maintainability, updates plugins and dependencies for Java 25 and Gradle 9.5.1, refactors task execution to use modern Gradle APIs, and adds packaging and analysis adjustments to keep builds and tooling working under the new toolchain.