Windows下Knowage适配OpenJDK12遇错，求单Tomcat最优解决方案

首先得明确问题根源：Knowage是基于Java SE 8开发的，而Java 9及以后引入了模块化系统，移除了sun.misc.BASE64Encoder这类内部非标准API，同时javax.xml相关的部分包也被移出了核心类库，这就是你遇到兼容性错误的核心原因。下面针对你列出的方案逐一分析，并给出最优选择：

方案逐一分析 #

• 双Tomcat部署（Java8+Java12）：确实会造成服务器资源浪费，而且反向代理的配置、后续双实例维护都会增加复杂度，除非你的其他应用必须依赖Java12且完全无法降级，否则不建议采用。
• Fork源码修改维护：工作量极大，不仅要修改sun.misc.BASE64Encoder这类兼容代码，还要长期跟进上游Knowage的版本更新，适配新功能、修复漏洞，没有专门的开发团队支撑的话，这个方案几乎不可持续。
• 等待官方修复：不确定性太高，没法解决当前的业务需求，只能作为长期的备选方向，不能作为当下的解决方案。
• 引入Java8的rt.jar到Tomcat/lib：虽然测试能正常登录，但潜在风险不容忽视：
  • 类库冲突：Java8的rt.jar和Java12的核心类库可能存在同名类但实现不同的情况，运行时可能出现ClassCastException、方法行为不一致等难以排查的问题。
  • 模块化冲突：Java12的模块化系统会和rt.jar中的非模块化类库产生冲突，后续升级Tomcat或Java版本时可能引发更严重的兼容性故障。
  • 许可风险：如果使用的是Oracle JDK的rt.jar，还可能存在版权合规问题（OpenJDK相对宽松，但仍不推荐这种混用方式）。

最优解决方案推荐 #

首选方案：降级到OpenJDK 8 #

这是最稳妥、成本最低的方案。既然Knowage在Java SE 8下能正常运行，直接将Knowage关联的Tomcat环境切换到OpenJDK 8即可，完全规避所有兼容性问题，不需要额外配置或修改代码，维护成本极低。

备选方案（必须使用Java12时）：替换非标准API并补充缺失的依赖 #

如果你因为其他应用必须使用Java12，那么可以针对性修改兼容代码，而不是引入整个rt.jar：

1. 替换sun.misc.BASE64Encoder：用Java 8及以后自带的标准API java.util.Base64替代，这个类是Java官方推荐的BASE64编码实现，不存在兼容性问题。只需要找到Knowage中使用sun.misc.BASE64Encoder的代码，替换为Base64.getEncoder()和Base64.getDecoder()即可。
2. 补充javax.xml相关依赖：对于缺失的javax.xml类，单独引入对应的依赖（比如jaxb-api、jaxb-impl、jaxb-core等），版本选择兼容Java12的即可，不需要引入整个rt.jar。

这种方案的风险远低于直接混用rt.jar，而且是标准的兼容处理方式，后续维护也更可控。

内容的提问来源于stack exchange，提问作者dmcontador