Hi everyone,
I would like to share an idea we are currently considering: doing some external validation and tracking work around BTrace’s compatibility with future JDK versions.
This idea is not intended to ask 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, BTrace, as a Java dynamic tracing / instrumentation tool, needs to work across a wide range of user runtime environments. The main project still keeps a relatively low compilation compatibility baseline, while also continuing to adapt to newer JDK versions such as JDK 17, JDK 19, JDK 22, and later versions. This kind of strategy is important for a diagnostic tool, since it helps cover older environments while still keeping up with changes in newer JVMs.
Because of that, our goal is not to push BTrace to raise its minimum Java baseline right away. Instead, we would like to do early compatibility validation around future JDK versions, so that potential issues in newer JDK environments can be identified earlier.
This kind of validation may include, but is not limited to:
- Compatibility issues with the attach mechanism on newer JDKs
- javaagent / instrumentation loading issues
- Access restrictions introduced by the Java module system
- Issues caused by changes to JDK internal APIs
- ASM / bytecode parsing and transformation compatibility issues
- Behavioral differences in multi-version runtime code across different JDKs
- Issues when using BTrace with common environments such as Spark / Hadoop on newer JDKs
- Runtime differences across different JDK distributions or JRE/JDK images
- Compatibility issues in CI, build scripts, and test environments
- Issues users may encounter when using BTrace on JDK 17, JDK 21, JDK 25, or later versions
Our current idea is to maintain a small number of external experimental compatibility branches or test environments for future JDK versions. The official project can continue normal development on the current main branch, current compatibility 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 JDK adaptation work.
If there is real demand later on, we may maintain two or three external compatibility validation branches or test configurations for future 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 BTrace may face on future JDK versions as early as possible and provide useful information for future adaptation work, without adding extra maintenance burden to the official project.
Thank you for your time, and thank you for maintaining BTrace！
Hi everyone,
I would like to share an idea we are currently considering: doing some external validation and tracking work around BTrace’s compatibility with future JDK versions.
This idea is not intended to ask 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, BTrace, as a Java dynamic tracing / instrumentation tool, needs to work across a wide range of user runtime environments. The main project still keeps a relatively low compilation compatibility baseline, while also continuing to adapt to newer JDK versions such as JDK 17, JDK 19, JDK 22, and later versions. This kind of strategy is important for a diagnostic tool, since it helps cover older environments while still keeping up with changes in newer JVMs.
Because of that, our goal is not to push BTrace to raise its minimum Java baseline right away. Instead, we would like to do early compatibility validation around future JDK versions, so that potential issues in newer JDK environments can be identified earlier.
This kind of validation may include, but is not limited to:
Our current idea is to maintain a small number of external experimental compatibility branches or test environments for future JDK versions. The official project can continue normal development on the current main branch, current compatibility 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 JDK adaptation work.
If there is real demand later on, we may maintain two or three external compatibility validation branches or test configurations for future 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 BTrace may face on future JDK versions as early as possible and provide useful information for future adaptation work, without adding extra maintenance burden to the official project.
Thank you for your time, and thank you for maintaining BTrace！