(chore) - remove Java 20 from CI and add Java 25#1718
Conversation
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
… Java 25 This commit refactors the TerminalCommonNameValidator to work with Java 21+ by introducing an abstraction layer for certificate information. This fixes test compatibility issues with sealed JDK classes (X509Certificate, X500Principal) that cannot be mocked directly on Java 21+ versions. Changes: - Add CertificateInfo interface: A simple abstraction that provides only the subject name, decoupling the validator from JDK certificate classes - Add X509CertificateInfo adapter: Wraps X509Certificate to implement CertificateInfo for production use without requiring mocks - Refactor TerminalCommonNameValidator: Add overloaded validateCertificate method accepting CertificateInfo. Original method now delegates via adapter for 100% backwards compatibility - Refactor TerminalCommonNameValidatorTest: Mock the simple CertificateInfo interface instead of sealed JDK classes. Removes @DisabledIf annotation, allowing all 27 test cases to run on Java 25 Benefits: - Tests now pass on Java 21 and 25 without being disabled - Uses a clean design pattern (Adapter) rather than skipping tests - Maintains full backwards compatibility with existing SDK users - Future-proof for Java versions with more restrictive sealing Related PR: #1718 (chore: remove Java 20 from CI and add Java 25)
|
/gemini summarize |
Summary of ChangesThis pull request updates the project's build and testing infrastructure to align with current Java LTS versions, specifically migrating from Java 20 to Java 25 in the CI pipeline. A significant architectural change involves abstracting certificate handling to enhance testability and future-proof compatibility with evolving Java security features, such as sealed classes in Java 21+. Additionally, core testing dependencies have been updated, and build plugin configurations adjusted to support these changes. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Ignored Files
Activity
|
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request updates the CI to add Java 25 and removes Java 20, which involves refactoring certificate validation logic for better testability and compatibility. The Java code changes are well-executed and improve the codebase. However, I've identified critical issues in the pom.xml where non-existent versions for maven-surefire-plugin and Mockito dependencies are specified, which will cause the build to fail. Additionally, an unnecessary and incorrectly configured Mockito extension file has been added. My review includes suggestions to correct these issues.
src/test/resources/mockito-extensions/org.mockito.plugins.MockMaker
Outdated
Show resolved
Hide resolved
… 21+ compatibility **CI and Dependency Updates:** - Update GitHub Actions workflow to test Java 25 instead of Java 20 - Only test against LTS versions (11, 17, 21, 25) as recommended by Java community - Update Mockito to 5.21.0 for better Java 25 support - Explicitly configure maven-surefire-plugin (3.5.2) for test compatibility - Enable ByteBuddy inline mock maker via mockito.properties **Test Refactoring for Sealed Classes:** Refactor TerminalCommonNameValidator to work with Java 21+ by introducing an abstraction layer for certificate information. This fixes compatibility issues with sealed JDK classes (X509Certificate, X500Principal) that cannot be mocked directly in Java 21+. Changes: - Add CertificateInfo interface: Simple abstraction providing only subject name, decoupling validator from JDK certificate classes - Add X509CertificateInfo adapter: Wraps X509Certificate to implement CertificateInfo, usable in production without mocking - Refactor TerminalCommonNameValidator: Add overloaded validateCertificate method accepting CertificateInfo. Original method delegates via adapter for 100% backwards compatibility - Refactor TerminalCommonNameValidatorTest: Mock the simple CertificateInfo interface instead of sealed JDK classes. Removes @DisabledIf annotation, allowing all 27 test cases to run on Java 25 without skipping **Benefits:** - Tests pass on Java 21 and 25 without being disabled - Cleaner design using Adapter pattern instead of test skipping - Full backwards compatibility - existing SDK users see no breaking changes - Future-proof for Java versions with stricter sealing restrictions
514f02e to
4322ad9
Compare
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request effectively updates the project's pom.xml to include a new Mockito version property and the maven-surefire-plugin, aligning with the goal of supporting newer Java versions. The core change introduces a CertificateInfo interface and an X509CertificateInfo adapter, which is a robust architectural improvement. This abstraction decouples the TerminalCommonNameValidator from direct X509Certificate usage, enhancing testability and ensuring compatibility with future Java versions, particularly concerning sealed classes. The test suite has been appropriately updated to reflect these changes, demonstrating a thorough approach to maintaining code quality and future-proofing the library.
src/main/java/com/adyen/terminal/security/X509CertificateInfo.java
Outdated
Show resolved
Hide resolved
src/test/java/com/adyen/terminal/security/TerminalCommonNameValidatorTest.java
Show resolved
Hide resolved
- Update spotless-maven-plugin from 2.46.1 to 3.2.1 - Update google-java-format from 1.19.2 to 1.34.1 These newer versions are compatible with Java 25 and resolve the previous API incompatibility issues with sun.tools.javac.util.Log internal APIs that have been removed or changed in Java 25.
Description
This PR removes support for Java 20 on CI and adds Java 25. In general we should only test against LTS versions as those are what the vast majority of our clients should be using, and are the official, stable & supported versions from the Java community.