不是背叛 OptaPlanner是认祖归宗一、一切从一个看似无关的技术决策开始今年初公司 CTO 在全员 Tech Radar 会上定了一条明年 Q2 前核心后端服务需完成 JDK 21 适配。当时 APS 组的人相视一笑——对我们来说这条要求翻译成人话是你那个 OptaPlanner 7.x / 8.x到底还行不行我们回去做的第一件事不是立刻动手而是坐下来列了一张表选项JDK 21 兼容性官方维护Drools 生命周期我们的判断OptaPlanner 7.x❌ 反射大面积失败❌ 停更多年弃用淘汰OptaPlanner 8.x⚠️ 勉强能跑❌ 实质停更9.x 移除过渡态、无未来Timefold Solver✅ 一等公民✅ 活跃已剥离纯 CS长期解答案其实在列完这张表的 5 分钟内就清晰了。二、为什么不是再苟一阵子 8.x说实话8.x 在我们系统里跑得挺稳。但深入看了两个东西之后我们打消了先凑合用的念头2.1 官方社区的实况Red Hat 把 OptaPlanner 转交给 JBoss 社区后实际情况是最后一个 8.x 维护版本已是长尾新 Issue 大多无人响应关键 Bug包括我们吃过的SolverManagerProblem ID 泄漏没人修我们用 8.x 做过一次内部试验在 JDK 21 Spring Boot 3 下跑相同数据集出现了InaccessibleObjectExceptionDrools 残余反射MethodHandle访问限制警告部分-XX:EnableDynamicAgentLoading相关告警能绕过但感觉像在给一台老爷车焊零件。2.2 Timefold 是谁——这点很重要这一点必须说清楚否则跳船容易被误解为跟风。Timefold OptaPlanner 原核心团队出走后创立的社区项目。关键人物Geoffrey De Smet 等就是当年写 OptaPlanner 的人。API 设计理念、求解器内核、ConstraintStream DSL——都是同一批人继续演化。所以对我们而言这不是换个库而是OptaPlanner 的精神继承者换了块招牌继续干。我们组有人总结得很到位不是叛逃是跟着老船长换艘新船。三、迁移——说出来同事都不信就这坦白说最让我们意外的是迁移成本低到不好意思写周报。3.1 依赖替换Maven 示例!-- 去掉 -- dependency groupIdorg.optaplanner/groupId artifactIdoptaplanner-spring-boot-starter/artifactId /dependency !-- 换成 -- dependency groupIdai.timefold.solver/groupId artifactIdtimefold-solver-spring-boot-starter/artifactId version1.13.0/version /dependency3.2 import 全局替换IDE 里一键org.optaplanner.core.api → ai.timefold.solver.core.api org.optaplanner.core.config → ai.timefold.solver.core.config我们mes-aps模块涉及ApsConstraintProviderApsSolutionStartTimeUpdatingVariableListenerApsMain没有一个业务 if 分支需要改。3.3 配置文件前缀# before optaplanner: solver: termination: seconds-spent-limit: 60 # after timefold: solver: termination: seconds-spent-limit: 603.4 第一次跑起来的感受执行mvn clean verify启动点下排产——✅ 求解正常✅ 分数一致✅ 日志清爽Drools 反射警告全没了✅ JDK 21 下无--add-opens、无--add-reads我们在群里只发了一句话这就完了早知道去年就换。四、让我们真正睡得安稳的四件事迁移成功只是表面收益。深层收益是这四个。✅ 1. JDK 21 是一等公民不是兼容测试通过Timefold CI 矩阵里就包含 JDK 21和 GraalVM。Record、switch模式匹配、VirtualThread友好——这些都是在设计中考虑的不是事后打补丁。对我们来说意义是以后升 JDK 不再需要APS 组单独评估兼容性。✅ 2. SolverManager 的老毛病有被正视我们在第三篇写的 Problem ID 治理方案依然需要自己做这是应用层职责但Timefold 对SolverJob的状态暴露更清晰solverManager.getSolverJob(problemId)行为更可预测已知 8.x 中已终止 Job 偶发仍占用 slot的问题在社区被跟踪并修复用我们 Leader 的话说不一定帮你管 ID但至少不给你挖坑了。✅ 3. ConstraintStream 在持续变强我们原来担心的换了库会不会约束语义变——完全没发生。相反索引优化.join()withJoiners) 在新版本中有进一步调优ConstraintCollector扩展更丰富ConstraintExplanation对前端展示更友好方便我们做为什么扣分的可视化意味着将来做排产透明度 / 约束审计功能成本会更低。✅ 4. 有明确的版本节奏和长期承诺Timefold 按季度发布有 Roadmap、有 Release Notes、有社区 Slack。对比 OptaPlanner 8.x 的安静这种感觉很像从开一辆没人保修的旧车换成了有 4S 店的新车。五、我们最终给团队的演进路线总结结合前面三篇我们内部文档现在是这么写的并附一条铁律新项目禁止新建 OptaPlanner 依赖统一用 Timefold。六、写在最后——给还在犹豫的人如果你现在用的是 OptaPlanner 7.x 或 8.x在 JDK 17 下跑得好好的——我的建议依然是不用急。但你要清楚地知道两点8.x 是死胡同不要把它当终点Timefold 不是冒险试新而是 OptaPlanner 的正统延续我们这次跳船没有改一条约束规则、没有重写求解逻辑只是换了包名卸掉了 Drools 的历史包袱为 JDK 21 把地基打在了活项目上好的技术决策有时候不是大刀阔斧而是在合适的时间跟着对的人走。 为什么在 JDK 21 的时代，我们最终选择了“跳船“到 Timefold——以及这次跳船，为什么反而让我们睡得更安稳了
不是背叛 OptaPlanner是认祖归宗一、一切从一个看似无关的技术决策开始今年初公司 CTO 在全员 Tech Radar 会上定了一条明年 Q2 前核心后端服务需完成 JDK 21 适配。当时 APS 组的人相视一笑——对我们来说这条要求翻译成人话是你那个 OptaPlanner 7.x / 8.x到底还行不行我们回去做的第一件事不是立刻动手而是坐下来列了一张表选项JDK 21 兼容性官方维护Drools 生命周期我们的判断OptaPlanner 7.x❌ 反射大面积失败❌ 停更多年弃用淘汰OptaPlanner 8.x⚠️ 勉强能跑❌ 实质停更9.x 移除过渡态、无未来Timefold Solver✅ 一等公民✅ 活跃已剥离纯 CS长期解答案其实在列完这张表的 5 分钟内就清晰了。二、为什么不是再苟一阵子 8.x说实话8.x 在我们系统里跑得挺稳。但深入看了两个东西之后我们打消了先凑合用的念头2.1 官方社区的实况Red Hat 把 OptaPlanner 转交给 JBoss 社区后实际情况是最后一个 8.x 维护版本已是长尾新 Issue 大多无人响应关键 Bug包括我们吃过的SolverManagerProblem ID 泄漏没人修我们用 8.x 做过一次内部试验在 JDK 21 Spring Boot 3 下跑相同数据集出现了InaccessibleObjectExceptionDrools 残余反射MethodHandle访问限制警告部分-XX:EnableDynamicAgentLoading相关告警能绕过但感觉像在给一台老爷车焊零件。2.2 Timefold 是谁——这点很重要这一点必须说清楚否则跳船容易被误解为跟风。Timefold OptaPlanner 原核心团队出走后创立的社区项目。关键人物Geoffrey De Smet 等就是当年写 OptaPlanner 的人。API 设计理念、求解器内核、ConstraintStream DSL——都是同一批人继续演化。所以对我们而言这不是换个库而是OptaPlanner 的精神继承者换了块招牌继续干。我们组有人总结得很到位不是叛逃是跟着老船长换艘新船。三、迁移——说出来同事都不信就这坦白说最让我们意外的是迁移成本低到不好意思写周报。3.1 依赖替换Maven 示例!-- 去掉 -- dependency groupIdorg.optaplanner/groupId artifactIdoptaplanner-spring-boot-starter/artifactId /dependency !-- 换成 -- dependency groupIdai.timefold.solver/groupId artifactIdtimefold-solver-spring-boot-starter/artifactId version1.13.0/version /dependency3.2 import 全局替换IDE 里一键org.optaplanner.core.api → ai.timefold.solver.core.api org.optaplanner.core.config → ai.timefold.solver.core.config我们mes-aps模块涉及ApsConstraintProviderApsSolutionStartTimeUpdatingVariableListenerApsMain没有一个业务 if 分支需要改。3.3 配置文件前缀# before optaplanner: solver: termination: seconds-spent-limit: 60 # after timefold: solver: termination: seconds-spent-limit: 603.4 第一次跑起来的感受执行mvn clean verify启动点下排产——✅ 求解正常✅ 分数一致✅ 日志清爽Drools 反射警告全没了✅ JDK 21 下无--add-opens、无--add-reads我们在群里只发了一句话这就完了早知道去年就换。四、让我们真正睡得安稳的四件事迁移成功只是表面收益。深层收益是这四个。✅ 1. JDK 21 是一等公民不是兼容测试通过Timefold CI 矩阵里就包含 JDK 21和 GraalVM。Record、switch模式匹配、VirtualThread友好——这些都是在设计中考虑的不是事后打补丁。对我们来说意义是以后升 JDK 不再需要APS 组单独评估兼容性。✅ 2. SolverManager 的老毛病有被正视我们在第三篇写的 Problem ID 治理方案依然需要自己做这是应用层职责但Timefold 对SolverJob的状态暴露更清晰solverManager.getSolverJob(problemId)行为更可预测已知 8.x 中已终止 Job 偶发仍占用 slot的问题在社区被跟踪并修复用我们 Leader 的话说不一定帮你管 ID但至少不给你挖坑了。✅ 3. ConstraintStream 在持续变强我们原来担心的换了库会不会约束语义变——完全没发生。相反索引优化.join()withJoiners) 在新版本中有进一步调优ConstraintCollector扩展更丰富ConstraintExplanation对前端展示更友好方便我们做为什么扣分的可视化意味着将来做排产透明度 / 约束审计功能成本会更低。✅ 4. 有明确的版本节奏和长期承诺Timefold 按季度发布有 Roadmap、有 Release Notes、有社区 Slack。对比 OptaPlanner 8.x 的安静这种感觉很像从开一辆没人保修的旧车换成了有 4S 店的新车。五、我们最终给团队的演进路线总结结合前面三篇我们内部文档现在是这么写的并附一条铁律新项目禁止新建 OptaPlanner 依赖统一用 Timefold。六、写在最后——给还在犹豫的人如果你现在用的是 OptaPlanner 7.x 或 8.x在 JDK 17 下跑得好好的——我的建议依然是不用急。但你要清楚地知道两点8.x 是死胡同不要把它当终点Timefold 不是冒险试新而是 OptaPlanner 的正统延续我们这次跳船没有改一条约束规则、没有重写求解逻辑只是换了包名卸掉了 Drools 的历史包袱为 JDK 21 把地基打在了活项目上好的技术决策有时候不是大刀阔斧而是在合适的时间跟着对的人走。