JBoss EAP 6.1 基于 Java 8 时代架构，未适配模块化（JPMS）和强封装机制，直接运行于 Java 17 会因 --add-opens 不足、内部 API 访问受限及 JAXP 重定向失败而崩溃，官方不支持且无可行的稳定升级路径。
jboss eap 6.1 基于 java 8 时代架构，未适配模块化（jpms）和强封装机制，直接运行于 java 17 会因 `--add-opens` 不足、内部 api 访问受限及 jaxp 重定向失败而崩溃，官方不支持且无可行的稳定升级路径。
JBoss EAP 6.1 发布于 2013 年（基于 AS 7.2），其底层模块系统（JBoss Modules 1.2.x）、类加载器逻辑、XML 处理栈（如 __redirected.__XMLInputFactory）均深度依赖 JDK 7/8 的非模块化行为与宽松反射策略。Java 9 引入的模块系统（JPMS）及后续版本（尤其是 Java 17 的强封装默认策略）彻底阻断了其关键内部类（如 com.sun.xml.internal.stream.XMLInputFactoryImpl）的反射访问路径——即使添加 --add-opens java.xml/com.sun.org.apache.xerces.internal.jaxp=ALL-UNNAMED 等参数，也无法覆盖 com.sun.xml.internal.stream 这一被 java.xml 模块明确禁止导出的私有包。
错误堆栈中的核心异常：
java.lang.IllegalAccessError: class __redirected.__XMLInputFactory cannot access class com.sun.xml.internal.stream.XMLInputFactoryImpl because module java.xml does not export com.sun.xml.internal.stream to unnamed module
清晰表明：EAP 6.1 的重定向机制试图通过反射实例化 JDK 内部 XML 工厂，但 Java 17 拒绝了该访问，且 --add-exports 无法用于导出被模块声明为 not exported 的内部包（JEP 261 明确限制）。
⚠️ 尝试“修复”的常见误区包括：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- 增加更多 --add-opens 或 --add-exports：无效，com.sun.xml.internal.* 属于被硬编码屏蔽的敏感内部 API；
- 替换 jboss-modules.jar 或修改 module.xml：EAP 6.1 的模块元数据与 Java 17 的模块解析器不兼容，极易引发 ModuleLoadException；
- 启用 --illegal-access=permit：该 JVM 参数在 Java 16+ 已被移除，Java 17 完全禁用非法反射。
✅ 正确应对路径只有两条：
- 降级 JDK 运行环境：严格使用 JDK 8u361（LTS）或 JDK 11（需验证补丁兼容性），这是 EAP 6.1 唯一受支持的运行时；
-
升级应用服务器：迁移至受 Java 17 官方支持的现代版本，例如：
- Red Hat JBoss EAP 7.4+（基于 WildFly 23+，完全支持 Java 17）
- WildFly 26+（原生 JPMS 适配，预置必要 --add-opens）
? 总结：JBoss EAP 6.1 与 Java 17 在架构层面不兼容，非配置问题，而是代际鸿沟。任何绕过模块限制的“hack”均不可靠，且违反 Java SE 向后兼容性契约。生产环境必须遵循 Red Hat 官方支持矩阵——EAP 6.1 的最高支持 JDK 版本为 Java 8。
