build(deps): upgrade dependencies and Gradle wrapper to latest versions#3585
Conversation
WalkthroughUpdated multiple dependency versions in Gradle build, bumped the Gradle wrapper to 9.2.0 (added zipStorePath), and removed explicit CLASSPATH initialization/usage from the Gradle wrapper scripts. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant DevShell as Developer shell
participant GradleWrapper as gradlew / gradlew.bat
participant Java as java process
rect rgb(230, 245, 255)
DevShell->>GradleWrapper: run wrapper script
GradleWrapper->>Java: execute "java -jar gradle-wrapper.jar ..."
Java-->>GradleWrapper: starts Gradle bootstrap
end
note over GradleWrapper,Java: Old flow included building a CLASSPATH and passing -classpath to java\nNew flow omits CLASSPATH and uses only -jar
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ 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). (11)
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.
Actionable comments posted: 2
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
gradle/wrapper/gradle-wrapper.jaris excluded by!**/*.jar
📒 Files selected for processing (4)
build.gradle.kts(5 hunks)gradle/wrapper/gradle-wrapper.properties(1 hunks)gradlew(1 hunks)gradlew.bat(1 hunks)
🔇 Additional comments (3)
gradlew (1)
1-248: LGTM!The wrapper script changes align with Gradle 9.2.0 standards, using
-jarinvocation without explicit CLASSPATH handling. The updated copyright and script structure are consistent with the official Gradle wrapper.gradlew.bat (1)
1-93: LGTM!The Windows wrapper script changes are consistent with Gradle 9.2.0 standards, using
-jarinvocation. The removal of explicit CLASSPATH handling aligns with the Unix wrapper script changes.gradle/wrapper/gradle-wrapper.properties (1)
3-3: I need to gather more specific information about compatibility requirements and any breaking changes.Based on the search results, I can now provide the final rewritten review comment:
Gradle 9.2.0 verified as released and stable.
Gradle 9.2.0 was released on October 31, 2025. The update from 9.1.0 to 9.2.0 is a minor version bump with no new breaking changes. For breaking changes, refer to the Gradle 9.x upgrade guide and full compatibility notes for Java, Groovy, Kotlin, and Android compatibility. A JVM version between 17 and 25 is required to execute Gradle. No known issues were discovered post-release for 9.2.0.
| } | ||
|
|
||
| val languageToolVersion = "6.6" | ||
| val languageToolVersion = "6.7" |
There was a problem hiding this comment.
🧩 Analysis chain
Verify dependency versions and security advisories.
These dependency upgrades span multiple libraries with version jumps of varying sizes. Ensure all versions exist and check for security vulnerabilities.
Run the following script to verify Maven Central versions and check for known security advisories:
Also applies to: 77-77, 112-112, 115-122, 156-156
🏁 Script executed:
#!/bin/bash
# Description: Verify dependency versions exist on Maven Central and check for security advisories
echo "=== Checking Maven Central versions ==="
# Check each dependency
declare -A deps=(
["org.languagetool:languagetool-core"]="6.7"
["com.github.ben-manes.caffeine:caffeine"]="3.2.3"
["org.aspectj:aspectjrt"]="1.9.25"
["commons-io:commons-io"]="2.20.0"
["commons-beanutils:commons-beanutils"]="1.11.0"
["commons-codec:commons-codec"]="1.20.0"
["org.apache.commons:commons-lang3"]="3.19.0"
["org.apache.commons:commons-collections4"]="4.5.0"
["org.apache.commons:commons-exec"]="1.5.0"
["org.jmockit:jmockit"]="1.50"
)
for dep in "${!deps[@]}"; do
version="${deps[$dep]}"
group="${dep%:*}"
artifact="${dep#*:}"
echo "Checking $dep:$version"
# Query Maven Central
response=$(curl -s "https://search.maven.org/solrsearch/select?q=g:${group}+AND+a:${artifact}+AND+v:${version}&rows=1&wt=json")
numFound=$(echo "$response" | jq -r '.response.numFound')
if [ "$numFound" = "0" ]; then
echo " ❌ Version $version NOT FOUND in Maven Central"
else
echo " ✓ Version $version found in Maven Central"
fi
done
echo ""
echo "=== Checking GitHub Security Advisories ==="
# Check for vulnerabilities using GitHub API
for dep in "${!deps[@]}"; do
package="${dep#*:}"
echo "Checking advisories for $package"
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: MAVEN, package: "'"$package"'") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}' 2>/dev/null || echo " (Unable to query GitHub API)"
doneLength of output: 1842
|
|
||
| // test utils | ||
| testImplementation("org.jmockit", "jmockit", "1.49") | ||
| testImplementation("org.jmockit", "jmockit", "1.50") |
There was a problem hiding this comment.
🧩 Analysis chain
Consider JMockit compatibility with Java 17.
JMockit 1.50 has known compatibility issues with Java 17 and newer JVMs due to its use of internal JVM APIs and bytecode manipulation. Since this project targets Java 17 (lines 161-162), you may encounter runtime issues.
Please verify that JMockit 1.50 works correctly with Java 17 and consider migrating to a maintained mocking framework like Mockito, which has better support for modern Java versions.
🌐 Web query:
JMockit 1.50 compatibility with Java 17
💡 Result:
Short answer: Yes — but with caveats.
- The original org.jmockit stopped active updates around 1.49 and had known Java 17 issues; community guidance was to switch to the maintained fork. [1][2]
- A 1.50 build (and later community-maintained releases under com.github.hazendaz) is available and is the recommended choice for Java 17 compatibility. If you hit JVM/instrumentation issues with org.jmockit:1.49, use the hazendaz-maintained artifact (com.github.hazendaz.jmockit:jmockit:1.50+) which users report working on Java 17. [1][3]
References
- Community notes on JMockit status / Java 17 issues and recommendation to use hazendaz fork. [1]
- JMockit group artifact listing showing 1.50 as latest. [2]
- Example project dependency showing com.github.hazendaz.jmockit:jmockit 1.50.0 in use. [3]
If you want, I can show the exact Maven coordinates and a sample pom/Gradle snippet to use the hazendaz artifact.
🏁 Script executed:
#!/bin/bash
# Extract the JMockit dependency line and Java version configuration
echo "=== JMockit dependency ==="
grep -n "jmockit" build.gradle.kts
echo -e "\n=== Java version configuration (lines 156-165) ==="
sed -n '156,165p' build.gradle.ktsLength of output: 545
Switch from org.jmockit to the maintained hazendaz fork for Java 17 compatibility.
The project uses org.jmockit:jmockit:1.50 with Java 17 target. The original org.jmockit stopped active updates around 1.49 and had known Java 17 issues; the community-maintained fork under com.github.hazendaz is available and recommended for Java 17 compatibility. Update the dependency:
testImplementation("com.github.hazendaz.jmockit", "jmockit", "1.50.0")
🤖 Prompt for AI Agents
In build.gradle.kts around line 156 the project references the unmaintained
org.jmockit:jmockit:1.50 which has Java 17 compatibility issues; replace that
dependency with the maintained hazendaz fork by switching to
com.github.hazendaz.jmockit:jmockit:1.50.0 in the testImplementation
configuration so the build uses the Java 17–compatible maintained artifact.
Описание
Связанные задачи
Closes
Чеклист
Общие
gradlew precommit)Для диагностик
Дополнительно
Summary by CodeRabbit