本文介绍如何通过 openrewrite 自动化工具，无需手动修改导入语句和依赖，快速、安全地将 optaplanner 项目升级至 timefold，显著提升求解性能。
本文介绍如何通过 openrewrite 自动化工具，无需手动修改导入语句和依赖，快速、安全地将 optaplanner 项目升级至 timefold，显著提升求解性能。
从 OptaPlanner 迁移到 Timefold 并非繁琐的重构工程，而是一次轻量、可逆、高度自动化的演进。Timefold 作为 OptaPlanner 的官方分支（自 2023 年正式分叉），在保持完全 API 兼容性的同时，持续优化求解器核心性能与开发体验。关键在于：所有迁移工作均可由 OpenRewrite 插件全自动完成——无需逐个替换包名、调整依赖坐标或重写注解。
✅ 迁移前准备：选择匹配版本
请严格遵循版本映射关系，确保迁移平滑：
- 若当前使用 OptaPlanner 8.x（如 8.29.0.Final），请选择 Timefold 0.8.x 系列（推荐 0.8.39 或更高补丁版本）；
- 若已升级至 OptaPlanner 9.x（如 9.0.0），则应选用 Timefold 1.x（当前稳定版为 1.0.0，预发布版可参考 0.9.x）。
版本错配可能导致迁移脚本无法识别旧 API 结构，引发部分转换遗漏。
⚙️ 一键执行迁移（Maven 示例）
在项目根目录下，直接运行以下 Maven 命令（以 OptaPlanner 8 → Timefold 0.8.x 为例）：
mvn org.openrewrite.maven:rewrite-maven-plugin:4.46.0:run \ -Drewrite.recipeArtifactCoordinates=ai.timefold.solver:timefold-solver-migration:0.8.39 \ -Drewrite.activeRecipes=ai.timefold.solver.migration.ToLatest
? 提示：Gradle 用户请访问 Timefold 官方迁移指南 获取对应 gradle.properties 配置及插件应用方式。
该命令将自动完成以下操作：
- 替换全部 org.optaplanner.* 包导入为 ai.timefold.solver.*；
- 更新 pom.xml 中的依赖坐标（optaplanner-solver → timefold-solver-core 等）；
- 调整注解类名（如 @PlanningSolution 保留语义，但指向新包路径）；
- 修正配置文件（如 application.properties 中的 optaplanner. 前缀自动转为 timefold.）。
✅ 验证与收尾
迁移完成后，请务必执行以下验证步骤：
- 编译通过：确保 mvn compile 无报错；
- 运行求解器：启动应用并触发一次完整规划流程；
-
比对性能日志：重点关注控制台末尾的 score calculation speed 指标，例如：
INFO Solving ended: ... score calculation speed (103322/sec) ...
Timefold 在相同硬件下通常比 OptaPlanner 同版本快 10%–30%，若数值明显提升，说明迁移生效；
- 提交变更：将 pom.xml、Java 源码、配置文件等变更纳入 Git 提交，建议附注 chore: migrate from OptaPlanner to Timefold v0.8.39。
⚠️ 注意事项
- 迁移脚本不会修改业务逻辑代码（如 ConstraintProvider 实现、自定义 Move 类等），这些需开发者自行确认兼容性；
- 若项目使用了 OptaPlanner 社区版未公开的内部 API（如 DefaultSolverFactory 的非公开方法），需参照 Timefold Javadoc 替换为标准扩展点；
- 强烈建议在迁移前创建 Git 分支并备份，以便快速回退。
迁移不是终点，而是起点——拥抱 Timefold 意味着获得更活跃的维护、更快的求解速度，以及面向云原生与 Spring Boot 3+ 的持续演进支持。现在，就用一条命令开启你的优化新阶段。
