What would you like to share?
Hi everyone,
Looking back on the project’s maintenance history, the community seems to have shown a positive stance toward JDK baseline upgrades. As notable precedents, the project upgraded its Java baseline to 17 via PR #2819 and later migrated to Java 21 in #5163.
Based on that, I wanted to share an idea for doing some early compatibility work for possible future JDK baseline upgrades, instead of only discovering migration issues when an official upgrade becomes necessary.
To clarify upfront, this is not a request for the upstream project to maintain multiple official codebases, ship separate releases for different Java versions, replace the existing test suite, or maintain a performance-focused fork.
The goal is to do early risk detection by testing compatibility against newer LTS JDK releases after the current Java 21 baseline, such as JDK 25 or later LTS versions.
If the project considers moving its build/source baseline to a newer Java version in the future, this kind of validation may help surface issues earlier, including:
- Build compilation failures
- Broken unit/integration tests
- Runtime behavior differences
- Dependency or build toolchain incompatibilities
- CI/environment setup issues
- End-user or contributor issues on newer Java runtimes
The current idea is to maintain a small set of experimental compatibility branches externally, while the upstream main branch continues normal development on the current official JDK baseline.
We would be responsible for:
- Syncing with upstream
- Running tests
- Maintaining these experimental branches
- Reporting useful compatibility findings back upstream
These branches would remain unofficial unless the project and community later find clear value in them. At this stage, their purpose would mainly be compatibility testing, collecting feedback, and preparing migration reference information.
If there is sustained community interest, we may maintain two or three external branches targeting newer JDK baselines. When we find concrete compatibility issues, we would try to submit small, focused PRs instead of asking the project to review or maintain a large fork.
The goal is to reduce future migration risk and provide useful compatibility information without adding extra maintenance burden to the official project.
Thanks for your time and for maintaining this project.
Additional information
No response
What would you like to share?
Hi everyone,
Looking back on the project’s maintenance history, the community seems to have shown a positive stance toward JDK baseline upgrades. As notable precedents, the project upgraded its Java baseline to 17 via PR #2819 and later migrated to Java 21 in #5163.
Based on that, I wanted to share an idea for doing some early compatibility work for possible future JDK baseline upgrades, instead of only discovering migration issues when an official upgrade becomes necessary.
To clarify upfront, this is not a request for the upstream project to maintain multiple official codebases, ship separate releases for different Java versions, replace the existing test suite, or maintain a performance-focused fork.
The goal is to do early risk detection by testing compatibility against newer LTS JDK releases after the current Java 21 baseline, such as JDK 25 or later LTS versions.
If the project considers moving its build/source baseline to a newer Java version in the future, this kind of validation may help surface issues earlier, including:
The current idea is to maintain a small set of experimental compatibility branches externally, while the upstream main branch continues normal development on the current official JDK baseline.
We would be responsible for:
These branches would remain unofficial unless the project and community later find clear value in them. At this stage, their purpose would mainly be compatibility testing, collecting feedback, and preparing migration reference information.
If there is sustained community interest, we may maintain two or three external branches targeting newer JDK baselines. When we find concrete compatibility issues, we would try to submit small, focused PRs instead of asking the project to review or maintain a large fork.
The goal is to reduce future migration risk and provide useful compatibility information without adding extra maintenance burden to the official project.
Thanks for your time and for maintaining this project.
Additional information
No response