chore: update stale dependencies, off the logback/slf4j alpha pins - #720
Merged
Conversation
|
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:
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe pull request adds ChangesDependency Refresh
Estimated code review effort: 3 (Moderate) | ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
build.gradle.kts (3)
120-121: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRefresh Guava consistently in the declaration and lockfile.
Guava
33.6.0is the current release. Update the direct dependency and regenerate the related lock entries. (github.com)
build.gradle.kts#L120-L121: change Guava to33.6.0-jre.gradle.lockfile#L15-L16: regenerate Guava and its resolved transitive entries.🤖 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 `@build.gradle.kts` around lines 120 - 121, Update the Guava dependency declaration in build.gradle.kts to 33.6.0-jre. Regenerate the corresponding Guava and resolved transitive dependency entries in gradle.lockfile so the lockfile matches the refreshed direct dependency.
141-144: 📐 Maintainability & Code Quality | 🔵 Trivial | 🏗️ Heavy liftVerify the JUnit major-version target.
The project targets JDK 17, and JUnit
6.1.0is now GA. JUnit 6 requires Java 17, while the JUnit support table no longer supports versions below5.14.x. Confirm whether this PR should migrate from5.12.2instead of stopping at the older 5.x line. (github.com)🤖 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 `@build.gradle.kts` around lines 141 - 144, Verify the JUnit version target in the test dependency declarations and, since the project targets JDK 17, migrate the JUnit API, params, and engine dependencies from 5.12.2 to the intended supported major line, using one consistent version across all three declarations.
113-115: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse one current SLF4J version across all configurations.
SLF4J
2.0.18is current stable. Update the runtime constraint, test pin, and lockfile together. (slf4j.org)
build.gradle.kts#L113-L115: raise the upper bound to2.0.18.build.gradle.kts#L159-L159: update the test dependency to2.0.18.gradle.lockfile#L105-L105: regenerate the locked version to2.0.18.🤖 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 `@build.gradle.kts` around lines 113 - 115, Use SLF4J 2.0.18 consistently: update the runtime constraint in build.gradle.kts lines 113-115, the test dependency in build.gradle.kts line 159, and the corresponding lock entry in gradle.lockfile line 105; regenerate or refresh the lockfile so all configurations resolve to 2.0.18.
🤖 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 `@build.gradle.kts`:
- Around line 116-118: Upgrade the Logback dependency in build.gradle.kts at
lines 116-118 to a patched release such as 1.5.37, verifying existing Logback
configuration compatibility; then regenerate both corresponding Logback entries
in gradle.lockfile at lines 5-6 so the lockfile matches the selected version.
---
Nitpick comments:
In `@build.gradle.kts`:
- Around line 120-121: Update the Guava dependency declaration in
build.gradle.kts to 33.6.0-jre. Regenerate the corresponding Guava and resolved
transitive dependency entries in gradle.lockfile so the lockfile matches the
refreshed direct dependency.
- Around line 141-144: Verify the JUnit version target in the test dependency
declarations and, since the project targets JDK 17, migrate the JUnit API,
params, and engine dependencies from 5.12.2 to the intended supported major
line, using one consistent version across all three declarations.
- Around line 113-115: Use SLF4J 2.0.18 consistently: update the runtime
constraint in build.gradle.kts lines 113-115, the test dependency in
build.gradle.kts line 159, and the corresponding lock entry in gradle.lockfile
line 105; regenerate or refresh the lockfile so all configurations resolve to
2.0.18.
🪄 Autofix
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 Plus
Run ID: c6d0b25f-3cf9-4a9d-b911-0d49a661b056
📒 Files selected for processing (2)
build.gradle.ktsgradle.lockfile
soloturn
force-pushed
the
chore/update-stale-dependencies
branch
from
August 6, 2026 02:46
232cc70 to
49d541c
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
❌ The last analysis has failed. |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 `@build.gradle.kts`:
- Around line 74-80: Update the dependency-locking setup around
resolutionStrategy.activateDependencyLocking() to lock every resolved
configuration relied on by the build, using
dependencyLocking.lockAllConfigurations() or explicitly covering compile,
runtime, test, and plugin classpath configurations. Regenerate gradle.lockfile
accordingly, and update the dependency table in README.md to accurately describe
the configurations that are locked.
- Around line 74-77: Update the lockfile-related prose in build.gradle.kts lines
74-77 and README.md lines 251-256 to clarify that dependency resolution uses
currently cached repository metadata, which may be up to Gradle’s 24-hour cache
duration. Mention --refresh-dependencies as the option users can pass to force
repository metadata checks, while preserving the existing explanation of
lockfile behavior.
In `@gradle.lockfile`:
- Around line 8-11: Regenerate gradle.lockfile using patched Jackson releases
for jackson-core, jackson-databind, and jackson-bom, keeping all Jackson
BOM/modules on the same patched release line. Verify dependency resolution
introduces no transitive constraint that restores version 2.20.0.
🪄 Autofix
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 Plus
Run ID: 8ddc7107-7978-45de-ad8c-d704a52cffc5
📒 Files selected for processing (3)
README.mdbuild.gradle.ktsgradle.lockfile
4 tasks
soloturn
force-pushed
the
chore/update-stale-dependencies
branch
from
August 7, 2026 20:11
152bcb3 to
d85fa3b
Compare
soloturn
added a commit
that referenced
this pull request
Aug 8, 2026
The Logback CVE finding was already fixed by an earlier commit (49d541c) on this branch. Three remained: - Lock every resolvable configuration, not just compileClasspath. Switched from configurations.compileClasspath { activateDependencyLocking() } to project-wide dependencyLocking { lockAllConfigurations() } (still behind the existing -PnoLock opt-out) - otherwise runtimeClasspath, the test classpaths, etc. could each silently resolve a different version than what compileClasspath had pinned, undermining the "everyone's build uses the same versions" point of locking at all. - Pin Jackson to a patched release. github-api transitively pulls in Jackson 2.20.0, which has several 2026 CVEs (GHSA-72hv-8253-57qq, GHSA-r7wm-3cxj-wff9, GHSA-3pjw-73gf-8qr5, GHSA-5jmj-h7xm-6q6v, GHSA-hgj6-7826-r7m5, GHSA-j3rv-43j4-c7qm, GHSA-rmj7-2vxq-3g9f) fixed at 2.21.4+. Added `implementation(platform("com.fasterxml.jackson:jackson-bom:2.22.1"))` rather than pinning jackson-core/-databind/-annotations individually, so Jackson's own BOM keeps them aligned. - Clarified the --write-locks/-PnoLock docs (build.gradle.kts and README's dependency-versions table): both resolve against Gradle's already-cached repository metadata, which itself only refreshes at most once per 24h for a dynamic version - mentioned --refresh-dependencies for forcing a check past that. gradle.lockfile regenerated via --write-locks to reflect both the Jackson bump and the newly-locked runtime/test/plugin configurations. Verified with a full `./gradlew build` (compile + checkstyle + PMD + tests) before pushing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V3dYofgD6GW7V21k6Mzfud
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 `@build.gradle.kts`:
- Around line 127-129: Update the slf4j-api dependency configuration around the
implementation declaration to force one stable SLF4J version for both production
and test classpaths, then regenerate gradle.lockfile. Ensure the resulting
lockfile retains the stable version and removes 2.1.0-alpha1 from all resolved
dependency entries.
In `@gradle.lockfile`:
- Line 103: Remove the vulnerable commons-beanutils, avro, and assertj-core
versions by updating their owning direct dependencies, plugins, or compatible
constraints, then regenerate gradle.lockfile through the project’s
dependency-locking workflow. Do not edit the generated lockfile manually, and
verify the flagged artifacts no longer appear.
🪄 Autofix
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 Plus
Run ID: a69471ef-f577-47b6-b03f-386599755c93
📒 Files selected for processing (3)
README.mdbuild.gradle.ktsgradle.lockfile
🚧 Files skipped from review as they are similar to previous changes (1)
- README.md
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/push-validation.yml:
- Line 14: Update the actions/checkout step in the push-validation workflow to
set persist-credentials to false, preventing the checkout token from remaining
available to subsequent validation steps.
🪄 Autofix
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 Plus
Run ID: 0d189790-85f0-4192-ac61-daed5ba21811
📒 Files selected for processing (1)
.github/workflows/push-validation.yml
soloturn
added a commit
that referenced
this pull request
Aug 14, 2026
The Logback CVE finding was already fixed by an earlier commit (49d541c) on this branch. Three remained: - Lock every resolvable configuration, not just compileClasspath. Switched from configurations.compileClasspath { activateDependencyLocking() } to project-wide dependencyLocking { lockAllConfigurations() } (still behind the existing -PnoLock opt-out) - otherwise runtimeClasspath, the test classpaths, etc. could each silently resolve a different version than what compileClasspath had pinned, undermining the "everyone's build uses the same versions" point of locking at all. - Pin Jackson to a patched release. github-api transitively pulls in Jackson 2.20.0, which has several 2026 CVEs (GHSA-72hv-8253-57qq, GHSA-r7wm-3cxj-wff9, GHSA-3pjw-73gf-8qr5, GHSA-5jmj-h7xm-6q6v, GHSA-hgj6-7826-r7m5, GHSA-j3rv-43j4-c7qm, GHSA-rmj7-2vxq-3g9f) fixed at 2.21.4+. Added `implementation(platform("com.fasterxml.jackson:jackson-bom:2.22.1"))` rather than pinning jackson-core/-databind/-annotations individually, so Jackson's own BOM keeps them aligned. - Clarified the --write-locks/-PnoLock docs (build.gradle.kts and README's dependency-versions table): both resolve against Gradle's already-cached repository metadata, which itself only refreshes at most once per 24h for a dynamic version - mentioned --refresh-dependencies for forcing a check past that. gradle.lockfile regenerated via --write-locks to reflect both the Jackson bump and the newly-locked runtime/test/plugin configurations. Verified with a full `./gradlew build` (compile + checkstyle + PMD + tests) before pushing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V3dYofgD6GW7V21k6Mzfud
soloturn
force-pushed
the
chore/update-stale-dependencies
branch
from
August 14, 2026 20:49
258623c to
866c922
Compare
logback-classic was pinned to 1.3.0-alpha16 (never left alpha) and slf4j-api's version range had an alpha ceiling (2.0.0-alpha7) below the actual 2.0.0 GA release, so it could never resolve above 1.7.x - both several years behind and needlessly on pre-release builds. Worse, anything on the 1.5.x branch through 1.5.24 (which an earlier version of this change picked) is vulnerable to CVE-2026-1225, an arbitrary class instantiation issue in configuration file processing - fixed in 1.5.25, or 1.6.1 (the actual latest, a drop-in replacement per upstream). Bumped everything found to be behind current stable on Maven Central, double-checked against the authoritative maven-metadata.xml for each artifact after an earlier pass trusted a stale search.maven.org index and missed several: logback-classic 1.6.1, slf4j-api range ceiling/test pin to 2.0.18, gson 2.14.0, guava 33.6.0-jre, everit json-schema 1.14.6, github-api 1.330 (staying off the 2.0-rc line), semver4j 6.0.0, okhttp/mockwebserver 5.4.0, hamcrest 3.0, junit-jupiter 6.1.2 (requires JDK 17 minimum itself - matches our pin exactly), mockito 5.23.0, mock-client 2.1.0. Left alone (already current, or deliberately pinned): - flexmark-all, fx-gson, testfx, spf4j-slf4j-test were already at latest stable. - error_prone_core stays on 2.42.0 - 2.43+ needs JDK 21 to run as a javac plugin (see existing comment, PR #719 review). - openjfx-monocle stays on the 17.0.10 variant - it publishes one build per target JDK line (11.0.2, 17.0.10, 21.0.2, ...), and 17.0.10 is the one matching our JDK 17 pin, not something to "upgrade" past. ## Test plan - `./gradlew :dependencies --write-locks` resolves cleanly, no conflicts. - `./gradlew compileJava` clean under JDK 17. - `./gradlew check` (tests, checkstyle, error-prone, pmd) passes under JDK 17, including all 11 test classes actually re-running (not cached) against the new okhttp 5.x / JUnit 6.x / logback 1.6.x. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PQriAKnoCEqcmFoSAvU39Q
…ild modes
Switches most dependency declarations from exact pins to open-ended
ranges (e.g. "[2.14.0,)" - 2.14.0 or newer), relying entirely on
gradle.lockfile (already active for compileClasspath) for
reproducibility instead of manually re-auditing every pin by hand.
Two exceptions where an open range would be wrong, not just
unnecessary:
- error_prone_core stays bounded below 2.43 (needs JDK 21 to run as a
javac plugin past that - see the existing comment). Initially bounded
error_prone_annotations the same way, but that's just marker-annotation
definitions with no such runtime ceiling of its own, and guava has a
strict transitive requirement on a newer one - matching the ceiling
there made resolution unsatisfiable. Left it open.
- openjfx-monocle is bounded to the 17.x line specifically
("[17.0,18.0)"), since it publishes one build per target JDK
(11.0.2, 17.0.10, 21.0.2, ...) rather than a sequential version
history - an open range would happily jump to a build meant for a
different JDK.
- github-api stays an exact pin, not a range: avoiding the 2.0-rc
pre-release line via a "<2.0" bound isn't reliably safe given how
Gradle's dynamic-version comparator orders pre-release qualifiers.
Also adds an opt-out (-PnoLock) for locally trying a fresh resolution
without writing to the lockfile, and documents all three build modes
(normal/locked, --write-locks, -PnoLock) in the README.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PQriAKnoCEqcmFoSAvU39Q
The Logback CVE finding was already fixed by an earlier commit (49d541c) on this branch. Three remained: - Lock every resolvable configuration, not just compileClasspath. Switched from configurations.compileClasspath { activateDependencyLocking() } to project-wide dependencyLocking { lockAllConfigurations() } (still behind the existing -PnoLock opt-out) - otherwise runtimeClasspath, the test classpaths, etc. could each silently resolve a different version than what compileClasspath had pinned, undermining the "everyone's build uses the same versions" point of locking at all. - Pin Jackson to a patched release. github-api transitively pulls in Jackson 2.20.0, which has several 2026 CVEs (GHSA-72hv-8253-57qq, GHSA-r7wm-3cxj-wff9, GHSA-3pjw-73gf-8qr5, GHSA-5jmj-h7xm-6q6v, GHSA-hgj6-7826-r7m5, GHSA-j3rv-43j4-c7qm, GHSA-rmj7-2vxq-3g9f) fixed at 2.21.4+. Added `implementation(platform("com.fasterxml.jackson:jackson-bom:2.22.1"))` rather than pinning jackson-core/-databind/-annotations individually, so Jackson's own BOM keeps them aligned. - Clarified the --write-locks/-PnoLock docs (build.gradle.kts and README's dependency-versions table): both resolve against Gradle's already-cached repository metadata, which itself only refreshes at most once per 24h for a dynamic version - mentioned --refresh-dependencies for forcing a check past that. gradle.lockfile regenerated via --write-locks to reflect both the Jackson bump and the newly-locked runtime/test/plugin configurations. Verified with a full `./gradlew build` (compile + checkstyle + PMD + tests) before pushing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V3dYofgD6GW7V21k6Mzfud
setup-java@v4 is deprecated. check-run-reporter/action@v2.11.1 is also listed in the forced-Node24 warning, but its newest release (v2.13.1, July 2024) predates that deprecation notice entirely - no newer tag actually fixes it, so left as-is. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V3dYofgD6GW7V21k6Mzfud
Missed this one earlier - only bumped setup-java last time. check-run-reporter/action@v2.11.1 still can't be fixed the same way: its newest release (v2.13.1, July 2024) predates the Node20 deprecation notice entirely, so no version bump addresses it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V3dYofgD6GW7V21k6Mzfud
Fixes #694. GitHub withholds repo secrets (CHECK_RUN_REPORTER_TOKEN included) from pull_request-triggered runs originating from a fork - the action then tries to authenticate with an empty token and 403s, which fails the whole Push Validation job even though the actual build/test/analysis all passed. Guard both upload steps on the token actually being present instead; they now just skip (shown as a gray skip in the UI, not a failure) rather than attempting and failing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V3dYofgD6GW7V21k6Mzfud
`secrets` is not an available context in a step-level `if:` — GitHub exposes it to `with:` and `env:` only. Naming it there does not evaluate to empty and skip the step; it fails validation of the whole workflow file, so no job runs at all. That is the state the branch was in: the last two pushes produced runs with zero jobs, listed under the raw path `.github/workflows/push-validation.yml` rather than the workflow's `name:` — GitHub's tell for a file it could not parse — and the PR consequently had no check runs and an `unknown` mergeable state. So none of the dependency updates on this branch have been validated by CI yet. `env` is available to `if:`, so the token is hoisted to a job-level env var and tested through that. The intended behaviour is unchanged: skip the upload when the token is absent, which is the fork-PR case from #694. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…bump Three of the open-ended ranges promise something the range itself cannot keep. None of these change what resolves today — the lockfile still pins the same versions — they only constrain what a future `--write-locks` is allowed to pick. Guava publishes a `-jre` and an `-android` build of every release, and Gradle compares the numeric parts before the qualifier, so `34.0.0-android` ranks above `33.6.0-jre`. An open range would therefore let an update quietly move us onto the Android build, which targets an older Java with a reduced API surface; the suffix only breaks ties between two builds of the same version. Capped below 34. semver4j and junit-jupiter both carry a `because` about requiring JDK 17 — true of those major lines, but not something a future major inherits, and this project pins JDK 17 deliberately. Capped below the next major, matching the reasoning already applied to `error_prone_core`. The Jackson BOM went the other way, to a range: it is here to keep Jackson off vulnerable versions, so pinning it exactly means the next Jackson CVE needs a hand-edit — the staleness this branch exists to remove. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cervator
force-pushed
the
chore/update-stale-dependencies
branch
from
August 16, 2026 03:07
866c922 to
2b9f609
Compare
`actions/checkout` leaves its token configured for authenticated git commands unless told otherwise. This job runs none, so the token is reachable by the build, test and static-analysis steps for no benefit — and those steps run Gradle against dependency ranges, which is exactly the surface where a smaller blast radius is worth two lines. Raised by CodeRabbit via zizmor (`artipacked`) on this PR. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cervator
approved these changes
Aug 16, 2026
Cervator
left a comment
Cervator
left a comment
Member
There was a problem hiding this comment.
Took this for an agent-assisted spin, tweaked a few things, tested, good to go :-)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
logback-classicwas pinned to1.3.0-alpha16(never left alpha) andslf4j-api's version range had an alpha ceiling (2.0.0-alpha7) below the actual 2.0.0 GA release, so it could never resolve above 1.7.x - both several years behind and needlessly on pre-release builds.Correction: an earlier version of this PR bumped
logback-classicto1.5.18, which is still vulnerable to CVE-2026-1225 (arbitrary class instantiation via compromised configuration file processing, affects everything before1.5.25). That version came from trusting a stalesearch.maven.orgsearch-index result instead of the authoritativemaven-metadata.xml- re-verified every dependency below against the latter after catching this.ch.qos.logback:logback-classic1.3.0-alpha161.6.1(fixes CVE-2026-1225; 1.6.x is upstream's drop-in replacement for 1.5.x)org.slf4j:slf4j-api(main, range ceiling)2.0.0-alpha72.0.18org.slf4j:slf4j-api(test)2.0.132.0.18com.google.code.gson:gson2.8.52.14.0com.google.guava:guava31.1-jre33.6.0-jrecom.github.everit-org.json-schema1.14.11.14.6org.kohsuke:github-api1.3181.330(staying off the2.0-rcline)org.semver4j:semver4j5.2.26.0.0com.squareup.okhttp3:okhttp4.12.05.4.0org.hamcrest:hamcrest2.23.0org.junit.jupiter:*5.10.26.1.2org.mockito:mockito-*5.18.05.23.0com.github.gmazzo.okhttp.mock:mock-client2.0.02.1.0com.squareup.okhttp3:mockwebserver4.10.05.4.0semver4j6.0.0 andjunit-jupiter6.1.2 both explicitly require JDK 17 minimum themselves - both match our pin exactly. Checked the only semver4j APIs this codebase uses (Semver.parse(), constructors) are unaffected by its builder-API rename.okhttp5.x's own changelog: separate JVM/Android artifacts (transparent under Gradle module metadata), and the oldmockwebservercoordinate (notmockwebserver3) continues being published, so no forced migration.Left alone (already current per
maven-metadata.xml, or deliberately pinned):flexmark-all,fx-gson,testfx,spf4j-slf4j-testwere already at latest stable.error_prone_corestays on2.42.0- 2.43+ needs JDK 21 to run as a javac plugin (see existing comment, PR feat(build): revive dynamic launch4j exe generation, fix Gradle 9 compat #719 review).openjfx-monoclestays on the17.0.10variant - it publishes one build per target JDK line (11.0.2,17.0.10,21.0.2, ...), and17.0.10is the one matching our JDK 17 pin, not something to "upgrade" past.Test plan
./gradlew :dependencies --write-locks- resolves cleanly, no conflicts../gradlew compileJava- clean under JDK 17../gradlew check(tests, checkstyle, error-prone, pmd) - passes under JDK 17; all 11 test classes re-ran (not cached) against the new okhttp 5.x / JUnit 6.x / logback 1.6.x and passed.