Hi everyone,
I would like to share an idea we are currently considering: doing some external validation and tracking work around Failsafe’s compatibility with newer JDK versions.
This is not a request for the official project to immediately raise its minimum Java baseline, maintain multiple codebases, create separate official releases for different Java versions, or replace the existing test suite. Our goal is also not to maintain a performance-focused fork.
From the current project setup, Failsafe is positioned as a lightweight, zero-dependency fault-tolerance library for Java 8+. The project currently still keeps Java 8 as its source/target baseline, which is important for supporting a broad range of JVM user environments. At the same time, the project already covers Java 8, Java 11, and Java 17 in CI, which shows that it values compatibility with newer JDKs while preserving the Java 8 baseline.
Because of that, our goal is not to push Failsafe to raise its minimum Java baseline right now. It is also not to ask the project to immediately change the current Java 8 source/target strategy. Instead, we would like to do external compatibility validation while the current compatibility strategy remains unchanged.
More specifically, we would like to build on the project’s existing JDK 17 test coverage and externally validate Failsafe’s build, test, and runtime behavior on JDK 17, JDK 21, JDK 25, and later versions. JDK 17 can serve as a reference point based on the existing CI coverage, while JDK 21, JDK 25, and later versions would help surface potential future compatibility risks earlier.
The purpose of doing this is to collect evidence in advance for possible future maintenance decisions. For example, if the project later considers expanding its CI matrix to JDK 21 / JDK 25, upgrading build plugins or dependencies, adjusting module-info / multi-release jar support, or eventually raising the minimum Java baseline, these external validation results could serve as useful reference material. They may help identify potential risks earlier, rather than discovering most compatibility issues only after an actual migration effort begins.
This kind of validation may include, but is not limited to:
- Whether Failsafe can be built reliably with JDK 17, JDK 21, JDK 25, or later versions while still keeping Java 8 source/target
- Whether the
core module test suite shows behavioral differences on newer JDKs
- Runtime behavior of core mechanisms such as async execution, scheduling, timeouts, retries, fallbacks, and circuit breakers on newer JDKs
- Concurrency-related behavior involving
CompletableFuture, thread scheduling, interruption, cancellation, and timeout handling on newer JDKs
- Compatibility issues related to the Java module system, module-info, multi-release jars, or reflective access
- Build and test behavior of integration modules such as OkHttp and Retrofit on newer JDKs
- Maven plugin, dependency resolution, test framework, or CI configuration issues on newer JDKs
- Issues users may encounter when using Failsafe on JDK 17, JDK 21, JDK 25, or later Java runtime environments
Our current idea is to maintain a small number of external experimental compatibility branches or test environments for newer JDK versions. The official project can continue normal development on the current main branch, current Java 8 baseline, current CI strategy, and existing release cadence. We would take responsibility for syncing with upstream, running relevant tests, recording issues, and maintaining these experimental validation efforts.
These branches or test environments are not intended to become official separate codebases unless the project and community later find clear value in them. At this stage, their main purpose would be compatibility validation, collecting feedback, and preparing useful reference information for future adaptation to newer JDKs, CI matrix expansion, dependency upgrades, or possible Java baseline changes.
If there is real demand later on, we may maintain two or three external compatibility validation branches or test configurations for newer JDK versions over the long term and report useful findings back upstream when helpful. For issues that can be addressed independently, we would try to document them as reproducible issues or submit small, focused PRs instead of asking the project to review or maintain a large fork.
The goal of this idea is to identify potential compatibility risks Failsafe may face on newer or future JDK versions as early as possible, without adding extra maintenance burden to the official project. We hope this can provide useful information for future maintenance, CI matrix expansion, dependency upgrades, or any possible future Java baseline adjustment.
Thank you for your time, and thank you for maintaining Failsafe.
Hi everyone,
I would like to share an idea we are currently considering: doing some external validation and tracking work around Failsafe’s compatibility with newer JDK versions.
This is not a request for the official project to immediately raise its minimum Java baseline, maintain multiple codebases, create separate official releases for different Java versions, or replace the existing test suite. Our goal is also not to maintain a performance-focused fork.
From the current project setup, Failsafe is positioned as a lightweight, zero-dependency fault-tolerance library for Java 8+. The project currently still keeps Java 8 as its source/target baseline, which is important for supporting a broad range of JVM user environments. At the same time, the project already covers Java 8, Java 11, and Java 17 in CI, which shows that it values compatibility with newer JDKs while preserving the Java 8 baseline.
Because of that, our goal is not to push Failsafe to raise its minimum Java baseline right now. It is also not to ask the project to immediately change the current Java 8 source/target strategy. Instead, we would like to do external compatibility validation while the current compatibility strategy remains unchanged.
More specifically, we would like to build on the project’s existing JDK 17 test coverage and externally validate Failsafe’s build, test, and runtime behavior on JDK 17, JDK 21, JDK 25, and later versions. JDK 17 can serve as a reference point based on the existing CI coverage, while JDK 21, JDK 25, and later versions would help surface potential future compatibility risks earlier.
The purpose of doing this is to collect evidence in advance for possible future maintenance decisions. For example, if the project later considers expanding its CI matrix to JDK 21 / JDK 25, upgrading build plugins or dependencies, adjusting module-info / multi-release jar support, or eventually raising the minimum Java baseline, these external validation results could serve as useful reference material. They may help identify potential risks earlier, rather than discovering most compatibility issues only after an actual migration effort begins.
This kind of validation may include, but is not limited to:
coremodule test suite shows behavioral differences on newer JDKsCompletableFuture, thread scheduling, interruption, cancellation, and timeout handling on newer JDKsOur current idea is to maintain a small number of external experimental compatibility branches or test environments for newer JDK versions. The official project can continue normal development on the current main branch, current Java 8 baseline, current CI strategy, and existing release cadence. We would take responsibility for syncing with upstream, running relevant tests, recording issues, and maintaining these experimental validation efforts.
These branches or test environments are not intended to become official separate codebases unless the project and community later find clear value in them. At this stage, their main purpose would be compatibility validation, collecting feedback, and preparing useful reference information for future adaptation to newer JDKs, CI matrix expansion, dependency upgrades, or possible Java baseline changes.
If there is real demand later on, we may maintain two or three external compatibility validation branches or test configurations for newer JDK versions over the long term and report useful findings back upstream when helpful. For issues that can be addressed independently, we would try to document them as reproducible issues or submit small, focused PRs instead of asking the project to review or maintain a large fork.
The goal of this idea is to identify potential compatibility risks Failsafe may face on newer or future JDK versions as early as possible, without adding extra maintenance burden to the official project. We hope this can provide useful information for future maintenance, CI matrix expansion, dependency upgrades, or any possible future Java baseline adjustment.
Thank you for your time, and thank you for maintaining Failsafe.