Feature description
Hi everyone,
I would like to share an idea about doing some compatibility validation work around possible future JDK baseline upgrades for termux-app.
This idea is not coming out of nowhere. Looking at the current project setup, termux-app already uses JDK 17 in its CI/build workflow, and the project has previously handled Gradle build compatibility issues related to JDK 17. At the same time, the Android code still keeps its source/target compatibility at Java 8.
Because of that, I think it is possible that a baseline upgrade may eventually become part of future maintenance work. If so, it may be useful to prepare for possible future JDK baseline upgrades in advance, instead of only dealing with migration issues when an upgrade becomes necessary. This could help make future maintenance work smoother and more efficient.
To be clear, this proposal is not asking the upstream project to change its official Java source baseline right now. It is also not asking the project to maintain multiple codebases, create Java-specific official releases, replace the existing test suite, or maintain a performance-focused fork.
My goal is to do early compatibility validation against newer build JDK environments and possible future baseline changes. For example, this could include testing with JDK 17, JDK 21, or later LTS releases, while still respecting the fact that the current source/target compatibility may remain unchanged unless the project decides otherwise.
If the project later considers moving its build setup, toolchain, or parts of its source baseline to a newer JDK, this work may help surface issues earlier, such as:
- Build or compilation failures
- Test failures
- Runtime behavior differences
- Dependency or Gradle / Android Gradle Plugin compatibility issues
- CI and environment setup problems
- Issues that users or contributors may encounter when building with newer Java runtimes
My current idea is to maintain a small number of experimental compatibility branches externally. The upstream main branch can continue normal development based on the current official setup, while we take responsibility for syncing, testing, and maintaining those experimental branches.
These branches 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 is to validate compatibility, collect feedback, and prepare useful migration reference information.
If there is sustained community interest, we may maintain two or three external compatibility branches targeting newer JDK environments over the long term and report useful findings back upstream. When appropriate, we would submit small, focused PRs for concrete compatibility issues instead of asking the project to review or maintain a large fork.
The goal of this early-stage idea 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 thanks for maintaining Termux.
Additional information
empty
Feature description
Hi everyone,
I would like to share an idea about doing some compatibility validation work around possible future JDK baseline upgrades for
termux-app.This idea is not coming out of nowhere. Looking at the current project setup,
termux-appalready uses JDK 17 in its CI/build workflow, and the project has previously handled Gradle build compatibility issues related to JDK 17. At the same time, the Android code still keeps its source/target compatibility at Java 8.Because of that, I think it is possible that a baseline upgrade may eventually become part of future maintenance work. If so, it may be useful to prepare for possible future JDK baseline upgrades in advance, instead of only dealing with migration issues when an upgrade becomes necessary. This could help make future maintenance work smoother and more efficient.
To be clear, this proposal is not asking the upstream project to change its official Java source baseline right now. It is also not asking the project to maintain multiple codebases, create Java-specific official releases, replace the existing test suite, or maintain a performance-focused fork.
My goal is to do early compatibility validation against newer build JDK environments and possible future baseline changes. For example, this could include testing with JDK 17, JDK 21, or later LTS releases, while still respecting the fact that the current source/target compatibility may remain unchanged unless the project decides otherwise.
If the project later considers moving its build setup, toolchain, or parts of its source baseline to a newer JDK, this work may help surface issues earlier, such as:
My current idea is to maintain a small number of experimental compatibility branches externally. The upstream main branch can continue normal development based on the current official setup, while we take responsibility for syncing, testing, and maintaining those experimental branches.
These branches 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 is to validate compatibility, collect feedback, and prepare useful migration reference information.
If there is sustained community interest, we may maintain two or three external compatibility branches targeting newer JDK environments over the long term and report useful findings back upstream. When appropriate, we would submit small, focused PRs for concrete compatibility issues instead of asking the project to review or maintain a large fork.
The goal of this early-stage idea 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 thanks for maintaining Termux.
Additional information
empty