围绕 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 版本中可能遇到的兼容性风险，并为后续适配提供有用的信息。

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