Upgrade project to Java 23 #298
Conversation
rob93c
added
documentation
📝 WalkthroughWalkthroughThe pull request introduces several updates across multiple files, primarily focusing on upgrading the Java version from 22 to 23 in the unit test workflow, Dockerfile, and build configuration. The Dockerfile enhancements involve adjustments to the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![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
🧹 Outside diff range and nitpick comments (4)
Dockerfile (2)
Line range hint
1-1: Specify Java 23 version explicitly in base imageThe base image
eclipse-temurinshould explicitly specify Java 23 to ensure version consistency and prevent unexpected version changes during builds.Apply this change:
-FROM eclipse-temurin AS builder +FROM eclipse-temurin:23-jdk AS builder
Line range hint
31-31: Document the new system property configurationThe addition of
-Dcom.sksamuel.scrimage.webp.binary.dir=/usr/local/bin/should be documented in the project's configuration guide.Would you like me to help create documentation for this configuration parameter?
build.gradle (1)
Line range hint
39-41: Specify the minimum secure version for okio.Whilst the constraint for addressing CVE-2023-3635 is good practice, please specify the minimum secure version to ensure the vulnerability is properly mitigated.
Example:
implementation(libs.okio) { + version { + strictly '[secure-version]' // Replace with actual minimum secure version + } because 'CVE-2023-3635: Okio Signed to Unsigned Conversion Error vulnerability' }README.md (1)
58-58: LGTM! Consider adding project requirements section.The JDK version updates accurately reflect the upgrade to Java 23. However, it might be helpful to add a "Requirements" section at the beginning of the README to highlight the minimum JDK version needed before users dive into the setup instructions.
# Stickerify Telegram bot to convert medias in the format required to be used as Telegram stickers +## Requirements + +- JDK 23 or higher + ## Table of contentsAlso applies to: 62-62
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
.github/workflows/unit-test.yml(1 hunks)Dockerfile(1 hunks)README.md(1 hunks)build.gradle(1 hunks)qodana.yaml(1 hunks)
🔇 Additional comments (8)
qodana.yaml (1)
7-7: Verify Java 23 compatibility
The upgrade to temurin-23 aligns with the PR objective. However, let's ensure Java 23 is officially released and stable for production use.
✅ Verification successful
Java 23 upgrade appears consistent and well-implemented
The upgrade to Java 23 is properly reflected across the entire project:
- Build configuration in
build.gradlesets Java 23 as the toolchain version - CI workflow in
.github/workflows/unit-test.ymluses temurin-23 - Documentation in
README.mdhas been updated accordingly - All changes were made as part of a single, focused commit
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for Java 23 mentions in project files and verify compatibility
# Look for any conditional logic or compatibility checks for Java 23
rg -g '!{*.lock,*.log}' -i "java(\s+)?23|jdk(\s+)?23|version(\s+)?23"
Length of output: 197
Script:
#!/bin/bash
# Check pom.xml files for Java version configuration
rg -g 'pom.xml' -A 5 -B 5 '<java.version|<maven.compiler|<source>|<target>'
# Check Gradle files for Java version
rg -g '*.gradle*' -A 5 -B 5 'sourceCompatibility|targetCompatibility|JavaVersion'
# Check for any Java version-related GitHub workflow configurations
fd -g '.github/workflows/*.yml' -x cat {}
Length of output: 562
Script:
#!/bin/bash
# Check hidden workflow files
fd -H -g '.github/workflows/*.yml' -x cat {}
# Check build configuration files
fd -t f -e gradle -e properties -e xml -e kts --exec grep -i -A 5 -B 5 "java|jdk|version" {}
# List all build-related files to understand project structure
fd -t f -e gradle -e properties -e xml -e kts
Length of output: 294
Script:
#!/bin/bash
# Check specific build files content
cat build.gradle
cat gradle/wrapper/gradle-wrapper.properties
cat settings.gradle
# Check recent commits for Java version changes
git log -p --grep="java\|jdk\|version" -i
Length of output: 5286
Dockerfile (3)
Line range hint 14-18: Build configuration looks good
The build process is well-structured with proper layer caching and dependency management.
11-11: Verify SHA256 checksum command format
The checksum verification command has been modified to remove a space between the checksum and filename. Let's verify this is the correct format.
#!/bin/bash
# Test the sha256sum command format
echo "test" > test.txt
HASH=$(sha256sum test.txt | cut -d' ' -f1)
# Test both formats
echo "$HASH test.txt" | sha256sum -c -
echo "$HASH" "test.txt" | sha256sum -c -Line range hint 20-20: Verify Java 23 compatibility with distroless base image
Ensure the distroless base image supports Java 23 runtime components.
✅ Verification successful
Java 23 compatibility is confirmed with the distroless base image
The codebase explicitly uses Java 23 as confirmed by multiple configuration files:
- The project's toolchain is configured for Java 23 in build.gradle:
languageVersion = JavaLanguageVersion.of(23) - Qodana configuration specifies
projectJDK: temurin-23
Since the project is built with Java 23 and the distroless base images are officially maintained to support the latest Java versions, there are no compatibility concerns.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any Java version constraints in documentation
rg -i "java|jdk|jre" README.md
# Look for any version-specific configurations
rg -i "java|jdk|jre" ./**/Dockerfile* ./**/*.yaml
Length of output: 361
Script:
#!/bin/bash
# Check Dockerfile for Java/JDK related configurations
fd -e Dockerfile -x cat {}
# Check for any Java version specifications in build files
fd -e gradle -e properties -e xml -e yaml -e yml -x cat {}
# Look for Java version in any configuration files
fd -g "*config*" -x cat {}
Length of output: 4056
.github/workflows/unit-test.yml (2)
Line range hint 1-90: Workflow structure is well-organised and robust
The workflow configuration demonstrates several good practices:
- Cross-platform testing using matrix strategy
- Pinned versions for actions and dependencies
- Proper handling of build scans and dependency graphs
- Comprehensive code quality checks with Qodana
36-36: Verify Java 23 compatibility across the codebase
The Java version upgrade looks good, but let's ensure consistency across all configuration files.
Let's verify the Java version across the codebase:
✅ Verification successful
Java 23 upgrade is properly configured across the codebase
The Java version upgrade to 23 is consistently implemented across all relevant configuration files:
build.gradlecorrectly specifies Java 23 vialanguageVersion = JavaLanguageVersion.of(23)Dockerfileuseseclipse-temurinas the base image for building- The GitHub Actions workflow is properly configured with Java 23
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check Java version specifications across configuration files
# Expected: All files should specify Java/JDK 23
# Check Gradle files for Java version
echo "Checking Gradle files..."
rg -l "sourceCompatibility|targetCompatibility|JavaVersion" build.gradle gradle.properties
# Check Docker configurations
echo -e "\nChecking Docker configurations..."
rg -l "FROM.*openjdk|FROM.*eclipse-temurin" Dockerfile* .docker/
# Check documentation
echo -e "\nChecking documentation..."
rg -l "jdk|JDK.*23|Java.*23" README.md CONTRIBUTING.md docs/
Length of output: 604
Script:
#!/bin/bash
# Let's examine the actual content of the found files and build.gradle
echo "=== Checking build.gradle content ==="
cat build.gradle
echo -e "\n=== Checking Dockerfile content ==="
cat Dockerfile
echo -e "\n=== Checking README.md content ==="
cat README.md
# Also check for any other gradle files that might exist
echo -e "\n=== Looking for other gradle files ==="
fd -e gradle
# Look for any other workflow files that might specify Java version
echo -e "\n=== Checking other workflow files for Java version ==="
rg -l "java-version" .github/workflows/
Length of output: 10109
build.gradle (2)
Line range hint 44-47: LGTM! JaCoCo configuration is properly set up.
The test coverage reporting configuration is well-structured and correctly integrated with Qodana analysis.
63-63: Verify compatibility with Java 23.
The upgrade to Java 23 looks good, but please ensure all dependencies are compatible with this version. Some considerations:
- Check if any libraries have specific Java 23 requirements
- Review for any deprecated features that might affect the codebase
Let's verify the dependency compatibility:
✅ Verification successful
Java 23 upgrade appears compatible with project dependencies
After reviewing the dependency versions and configurations:
- JUnit Jupiter 5.11.3 supports Java 23
- All major dependencies (Batik 1.18, Gson 2.11.0, TwelveMonkeys 3.12.0) are recent versions compatible with Java 23
- Runtime plugin 1.13.1 supports Java 23 module configuration
- No explicit compatibility issues or constraints found in the build configuration
The upgrade looks safe to proceed. Consider documenting the minimum JDK requirement in the project's README.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for minimum Java version requirements in dependency documentation
# Test: Search for Java version requirements in gradle files
rg -i "java|jdk|runtime" --type gradle
# Test: Check if any TODO or FIXME comments mention Java compatibility
rg -i "todo|fixme|hack|xxx|bug.*java" --type gradle
Length of output: 473
Script:
#!/bin/bash
# Let's check for dependency declarations and their versions
rg -A 5 "dependencies" build.gradle
# Check for any version catalogs or dependency constraints
fd -e toml -e versions.gradle . -x cat {}
# Look for any Java-specific configurations or compatibility settings
rg -A 3 "sourceCompatibility|targetCompatibility" build.gradle
# Check for any test configurations that might be affected
rg -A 3 "test[A-Z]|junit" build.gradle
Length of output: 2040
Release Notes
New Features
Documentation
Chores