AI 将 COBOL 迁移至 Java，连同 Bug 一起
AI migrated legacy COBOL programs to Java, bugs included
将遗留的 COBOL 程序迁移到 Java 时，测试数据的缺失和边界案例的验证难题往往让人头疼。这篇论文提出了一种名为 Locksmith Loop 的代理测试合成方法，通过在普通硬件上运行 COBOL 源程序和生成的 Java 目标程序，并利用 Mock 进行插桩，构建了一个迭代循环。该循环执行 Witness Search 以穿透程序分支，随后进行保持一致性的变异。当遇到路由边界时，分析器会识别出阻止深入探索的 Locked Paragraph。在三个案例研究中，Locksmith 显著提升了代码覆盖率，在两个开源项目中实现了近乎完全的覆盖，在内部生产级 COBOL 程序中达到了 91.90% 的分支覆盖率。生成的 Java 代码在所有通过确定性一致性检查的测试用例中，都与 COBOL 参考代码完全匹配。
在三个跨越两个开源程序和内部生产级 COBOL 程序的案例研究中，Locksmith 始终能够突破输入搜索的平台期，显著提升覆盖率。
HN 评论区
97- matsemann
以前，只有公司里那些资深的 COBOL 程序员才懂这套代码库。
现在，没人懂了。
我能理解从遗留的 COBOL 系统迁移出来的诱惑。但用 AI 重写实际上并没有解决任何遗留 COBOL 代码库的问题。你只是得到了一个没人了解、没人懂的新系统。
- toplinesoftsys
最大的问题并不是 Bug 会随着 COBOL 一起被迁移过来，而是会引入大量新的 Bug。AI 不是确定性的，它会犯下无数错误。唯一切实可行的低错误率方案是使用 Cursor 或类似工具进行渐进式、逐步迁移。但这需要更多时间，因为每一步都必须手动提示、测试并提交。任何指望一次性迁移大型代码库而不会引入海量 Bug 的想法都非常天真。LLM 在处理长上下文方面非常糟糕——不幸的是，这是它们的本性。这个问题目前还没有答案。
- pacaro
最大的测试案例是 4kloc。
而生产环境中存在着数百亿行 COBOL 代码。
仅 IRS（美国国税局）就有大约 160 个 COBOL 程序，平均每个 230kloc。
- mtct88
我为什么要将 COBOL 转换成 Java？
LLM 写 COBOL 写得一样好。
- kukkeliskuu
虽然并非所有内容都能轻松转换（如 IMS、CICS、报表、批处理等），但在许多情况下，自动化工具确实能对迁移有所帮助。
与此相关，我开发了一个工具，用于比较 COBOL 代码和 Java 代码。它包含一个预处理步骤，将 IMS 等调用转换为返回 JSON（来自文件）的 mock，同时输入/输出也使用 JSON，并利用 GnuCOBOL 运行程序。这更像是一个概念验证而非生产级工具，但如果有人觉得有用，这里是链接：