围绕 Arthas 未来 JDK 版本兼容性的外部验证工作

大家好，

我想分享一个我正在考虑的一个不成熟的想法：围绕 Arthas 对未来 JDK 版本的兼容性，提前做一些外部验证和跟踪工作。

这个想法的目的并不是要求官方项目去维护多套代码库，也不是要求官方创建针对不同 Java 版本的正式发布版本，更不是要替代现有测试套件。我们的目标也不是维护一个以性能为目的的 fork。

从项目目前的情况来看，Arthas 作为 Java 诊断工具，需要面对非常多样的用户运行环境。项目已经支持 JDK 8+，并且也在持续适配较新的 JDK 版本，例如 JDK 17、JDK 21，甚至后续 JDK 25 等版本。同时，项目主线仍然保持较低的编译兼容线，这对覆盖更多用户环境是很重要的。

因此，我的意思并不是推动 Arthas 立即提高最低 Java baseline，而是围绕未来 JDK 版本做一些提前的兼容性验证，帮助更早发现新 JDK 环境中可能出现的问题。

这类验证可能包括但不限于：

* attach 机制在新 JDK 上的兼容性问题
* instrumentation / agent 加载相关问题
* Java module system 带来的访问限制
* JDK 内部 API 变化导致的问题
* ASM / 字节码解析相关兼容性问题
* 不同 JDK 发行版或 JRE/JDK 镜像下的运行差异
* CI、构建脚本和测试环境中的兼容性问题
* 用户在 JDK 17、JDK 21、JDK 25 或后续版本中使用 Arthas 时可能遇到的问题

我目前的想法是，在外部维护少量面向较新 JDK 版本的实验性兼容分支或测试环境。官方项目仍然可以继续按照当前的主分支、当前的兼容策略和当前的发布节奏正常开发。我们会负责同步上游代码、运行相关测试、记录问题，并维护这些实验性验证工作。

当然，这些分支或测试环境并不是要直接变成官方的独立代码库，除非未来项目和社区认为它们确实有明确价值。现阶段，它们主要用于兼容性验证、收集反馈，并整理未来适配新 JDK 时可能有用的参考信息。

如果社区确实有相关需求，甚至可能会在外部长期维护两到三个面向较新 JDK 版本的兼容性验证分支或测试配置，并在有帮助时把发现反馈给上游项目。对于可以独立解决的问题，我也会尽量提交小范围、聚焦的 PR，而不是要求项目审查或维护一个大型 fork。

这个想法的最终目标，就是在不给官方项目增加额外维护负担的前提下，尽早发现 Arthas 在未来 JDK 版本中可能遇到的兼容性风险，并为后续适配提供有用的信息。

非常感谢大家能看到这里！

No specific files, tests, or entry points are named. Start by reviewing Arthas's existing JDK compatibility, CI, build, and test setup, then define a narrowly scoped validation target for newer JDK versions. Done should be a documented validation environment and actionable compatibility findings that can be reported upstream.

Written by the indexing model from the issue text.