Hi everyone,
I would like to share an early idea I have been considering: doing some external compatibility validation work around RxJava on possible future JDK environments.
The purpose of this idea is not to ask the official project to 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, RxJava 3.x has Java 8 as its minimum Java baseline, while also supporting execution on newer JDK versions, including JDK 17, JDK 21, and later LTS releases. Based on that, our goal is to do some early compatibility validation in case the project ever considers moving to a newer JDK baseline in the future.
If the project later considers upgrading its build/source baseline from the current Java 8 baseline to a newer JDK baseline, this work may help surface potential issues earlier, including:
- Compilation or build failures
- Unit or integration test failures
- Runtime behavior differences
- Third-party dependency compatibility issues
- CI / build script environment compatibility issues
- Issues users may encounter when using RxJava on newer JDK environments
Our current approach is to maintain a small number of external experimental compatibility branches targeting newer JDK baselines. The official project can continue normal development on the current main branch and current Java baseline. We would take responsibility for syncing with upstream, running relevant tests, recording issues, and maintaining these experimental branches.
These branches are not intended to become official separate codebases unless the project maintainers and community later find clear value in them. At this stage, their main purpose is compatibility validation, collecting community feedback, and providing migration reference information.
If we later find concrete issues such as build failures, test failures, runtime behavior differences, or dependency compatibility problems, we will document them as reproducible standalone issues, or submit small, focused PRs where appropriate.
If there is real community demand, we may maintain two or three external compatibility branches for newer JDKs over the long term and feed useful compatibility findings or small scoped PRs back upstream when helpful.
Hi everyone,
I would like to share an early idea I have been considering: doing some external compatibility validation work around RxJava on possible future JDK environments.
The purpose of this idea is not to ask the official project to 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, RxJava 3.x has Java 8 as its minimum Java baseline, while also supporting execution on newer JDK versions, including JDK 17, JDK 21, and later LTS releases. Based on that, our goal is to do some early compatibility validation in case the project ever considers moving to a newer JDK baseline in the future.
If the project later considers upgrading its build/source baseline from the current Java 8 baseline to a newer JDK baseline, this work may help surface potential issues earlier, including:
Our current approach is to maintain a small number of external experimental compatibility branches targeting newer JDK baselines. The official project can continue normal development on the current main branch and current Java baseline. We would take responsibility for syncing with upstream, running relevant tests, recording issues, and maintaining these experimental branches.
These branches are not intended to become official separate codebases unless the project maintainers and community later find clear value in them. At this stage, their main purpose is compatibility validation, collecting community feedback, and providing migration reference information.
If we later find concrete issues such as build failures, test failures, runtime behavior differences, or dependency compatibility problems, we will document them as reproducible standalone issues, or submit small, focused PRs where appropriate.
If there is real community demand, we may maintain two or three external compatibility branches for newer JDKs over the long term and feed useful compatibility findings or small scoped PRs back upstream when helpful.