^ Arthas 0.4 JDK →

Hello everyone, I would like to share an immature idea I am considering: to do some external validation and tracking work in advance around the compatibility of Arthas with future JDK versions. The purpose of this idea is not to require the official project to maintain multiple codebases, nor to require the official project to create official release versions for different Java versions, nor to replace the existing test suite. Our goal is not to maintain a fork that is optimized for performance. From the current situation of the project, as a Java diagnostic tool, Arthas needs to face a wide range of user environments. The project already supports JDK 8+ and is continuously adapting to newer JDK versions, such as JDK 17, JDK 21, and even future versions such as JDK 25. At the same time, the main line of the project still maintains a low compilation compatibility line, which is important for covering more user environments. Therefore, my intention is not to push Arthas to immediately raise the minimum Java baseline, but to do some pre-compatibility validation around future JDK versions to help identify potential problems in new JDK environments earlier. Such validations may include, but are not limited to: compatibility issues with the attach mechanism on new JDKs; instrumentation/agent loading-related issues; access restrictions brought by the Java module system; problems caused by changes in the internal API of the JDK; compatibility issues related to ASM/bytecode parsing; differences in execution under different JDK releases or JRE/JDK images; compatibility issues in CI, build scripts, and test environments; and problems that users may encounter when using Arthas in JDK 17, JDK 21, JDK 25, or later versions. My current idea is to maintain a small number of experimental compatibility branches or test environments for newer JDK versions externally. The official project can continue to develop normally according to the current main branch, the current compatibility strategy, and the current release rhythm. We will be responsible for synchronizing upstream code, running related tests, recording issues, and maintaining these experimental verification efforts. Of course, these branches or test environments are not intended to directly become independent codebases of the official project, unless the project and the community consider them to have clear value in the future. At this stage, they are mainly used for compatibility validation, collecting feedback, and organizing reference information that may be useful when adapting to new JDK versions in the future. If the community does have related needs, it is possible that two or three compatibility verification branches or test configurations for newer JDK versions will be maintained externally for a long time, and the discovered feedback will be provided to the upstream project when it is helpful. For problems that can be solved independently, I will also try to submit small-scale, focused PRs instead of requiring the project to review or maintain a large fork. The ultimate goal of this idea is to identify compatibility risks that Arthas may face in future JDK versions as early as possible, without adding additional maintenance burdens to the official project, and provide useful information for subsequent adaptation. Thank you very much for reading this!