是否有人曾尝试在Java/JDK 11环境下运行Drools 5.x版本？

我之前为了把绑死 Drools 5.5.0.Final 的老业务系统往 JDK 11 迁，实打实做过全场景适配测试，不是跑个最简化的 demo 就瞎下结论，实际踩的坑基本和你预判的一样——兼容性差到根本没法生产用：

• 首先是硬API缺失的死穴：Drools 5.x 当年的实现深度依赖JDK 8及更早版本的非公开内部API，比如硬编码调sun.misc.Unsafe的实例获取逻辑、sun.reflect.Reflection的方法参数扫描逻辑，这些类在JDK 11里要么被直接删了，要么被强模块封装锁死，哪怕你在启动参数里给所有相关模块加--add-opens开放反射权限，都解决不了部分类直接不存在的NoClassDefFoundError问题。
• 其次是字节码处理的版本断层：Drools 5.x 内置的是3.x版本的ASM类库，这个老版本根本读不懂JDK 11输出的class文件格式（版本号55.0），只要你绑到规则里的业务事实类是JDK 11编译出来的，Drools在做规则校验、类字段绑定的时候，会直接抛没有明确栈信息的ArrayIndexOutOfBoundsException，排查起来挠头到掉头发。
• 网上传的“加几个启动参数就能兼容”的偏方，实际测下来只能支撑最基础的测试场景：

  我当时补全了JDK 11里拆出去的JAXB、javax.annotation等独立依赖，把所有能开的模块反射权限全放开，最后也就只能跑通没有复杂绑定、没有动态规则更新、没有累积计算的单条简单drl脚本。一旦碰到规则热加载、多事实交叉匹配、规则结果持久化这类生产场景，短则半小时长则几小时就会触发类加载死锁、规则编译失败的问题，离生产可用的稳定性标准差得远。

• 当然也不是完全跑不起来：你要是就本地写个测试demo，把所有绑进规则的业务事实类都用JDK 8的编译版本打包，哪怕进程是跑在JDK 11上的，简单规则的输出结果和在JDK 8下跑没区别，但这种凑活的状态根本不算完成适配，稍微加一点业务复杂度就崩。

最后算过一笔经济账：硬要把Drools 5.x魔改到适配JDK 11的开发、测试、维护成本，比把全部现有规则迁移到兼容JDK 11的高版本Drools的成本高3倍都不止，完全没性价比。

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