Java 是企业 COBOL 迁移最常见的目标，其原因不难理解。它成熟、强类型、由庞大的库生态系统支撑，并得到英国最深厚的开发者人才库之一的支持。对于在 IBM 大型机上运行关键 COBOL 的组织而言，COBOL 到 Java 迁移提供了一条通往现代平台的路径，同时无需放弃这些系统所要求的企业级严谨性。

本指南阐述 COBOL 到 Java 迁移实际涉及哪些内容、英国企业可采用的方法、成本如何，以及如何管理风险。

摘要（TL;DR）

  • 凭借其成熟的生态系统、强类型和庞大的开发者库，Java 是大型企业默认的 COBOL 迁移目标
  • 金融精度不容妥协：COBOL 压缩十进制（COMP-3）字段必须映射到 Java 的 BigDecimal，绝不能映射到 double 或 float
  • 三种主要方法（自动化转换、并行重写和渐进式"绞杀榕"迁移）具有不同的风险和成本特征；大多数英国企业采用混合方式
  • 一次中等规模的迁移通常花费 200,000 至 800,000 英镑，耗时 一到两年；数据访问层和未记录的业务逻辑是最大的风险

为什么 Java 是默认的企业目标

Java 二十多年来一直是主流的企业语言，多个因素使其成为自然的 COBOL 目标：

成熟的企业生态系统。 Spring、Jakarta EE 和庞大的库目录涵盖了迁移后系统所需的一切：事务管理、消息传递、批处理（Spring Batch 能很好地映射到 COBOL 批处理作业）以及数据访问。

强大的静态类型。 Java 的类型系统在编译时捕获整类错误，这在翻译数十年间无人完整记录的业务逻辑时至关重要。

JVM 可移植性与运维。 JVM 可在任何地方运行，而且大多数英国企业已经在运行 JVM 工作负载，因此迁移后的 COBOL 能融入现有的部署、监控和安全工具。

开发者可获得性。 Java 无处不在地被教授和使用。其长期维护和招聘的人才库是所有语言中最大的之一，这直接降低了现代化风险。

你不能违背的十进制精度规则

这是 COBOL 到 Java 迁移中最重要的单一技术要点。COBOL 的 PIC 9 子句和 COMP-3 压缩十进制字段表示精确的十进制值，这正是金融系统所要求的。Java 的基本类型 double 和 float 使用二进制（IEEE 754）浮点数，会在货币计算中引入舍入误差。

正确的映射是 Java 的 BigDecimal ，其刻度和精度与原始 PIC 子句相匹配。BigDecimal 比基本类型更冗长，因为它是一个带有显式 API 的对象，但它保留了精确的算术运算。任何为了"保持代码简单"而将 COMP-3 转换为 double 的迁移，都是在引入生产缺陷。（这种冗长正是已在 .NET 技术栈上的组织有时更偏好 C# 的原因之一，C# 的原生 decimal 类型以更少的繁文缛节完成同样的工作；有关该比较，请参阅 COBOL 到 C# 迁移指南 。）

需要真正翻译的 COBOL 结构

安全的迁移翻译的是 COBOL 的语义，而非文本。需要真正映射到惯用 Java 17 的结构包括：

  • PERFORM 范围变成方法调用；段落和节分解为方法。
  • EVALUATE / WHEN 映射到 switch 语句或 switch 表达式。
  • 88-level 条件名变成布尔方法或枚举。
  • REDEFINES、OCCURS 和组项映射到类型化的类、数组和集合。
  • PIC 子句映射到正确的 Java 类型：字母数字用 String，定长整数用 int / long，十进制字段用 BigDecimal。
  • COPY 和 REPLACE（副本簿）必须被解析，包括嵌套的副本簿。
  • EXEC SQL（DB2）、EXEC CICS 和 VSAM 没有现成的 Java 对应物，需要有意地重新设计为 JDBC、JPA/Hibernate 或 Spring Data 以及现代服务模式。
  • EBCDIC 编码和定宽布局需要显式转换为 Unicode 和类型化模型。

迁移方法

主要有三种方法，每种都有不同的风险和成本特征。

1. 自动化转换

工具解析 COBOL 并生成等效的 Java。做得好时，输出是具有正确类结构、类型化字段、用于压缩十进制的 BigDecimal 以及结构化异常处理的惯用 Java 17。做得草率时，它会产生一种难以阅读的逐字转写，比原始 COBOL 更难维护。

最适合： 优先快速消除 COBOL 依赖、随后进行渐进式重构的大型代码库。

风险： 没有任何工具能产出一个完成的系统。嵌入式 SQL、CICS 交互和动态调用仍需人工决策。

Mecanik COBOL 到 Java 迁移工具 展示了优秀的自动化是什么样子：它构建完整的 Abstract Syntax Tree，运行语义分析，生成带有 BigDecimal 映射和结构化异常处理的惯用 Java 17，解析 COPY/REPLACE 指令，并生成一份 Migration Report，标记出每一处需要人工关注的 EXEC SQL、EXEC CICS、动态 CALL 以及十进制精度考量。

2. 并行重写

Java 系统与 COBOL 系统并行构建。两者处理相同的输入，并将输出相互验证，直到 Java 通过，此时 COBOL 被退役。

最适合： 连续性不容冒险的关键任务系统，例如支付、薪资和福利。

风险： 并行运行两个系统在迁移期间使运营成本翻倍，并要求严格的对账。

3. 渐进式迁移（绞杀榕）

COBOL 程序被逐个替换为 Java 对应物。系统先变成混合体，最终变为纯 Java。

最适合： 完全重写不切实际的大型单体 COBOL 系统。

风险： 混合状态可能比计划持续更久，并要求在 COBOL 与 Java 组件之间进行精心的接口设计。

对于大多数英国企业迁移而言，绞杀榕方法结合选择性的自动化转换，能在风险和速度之间提供最佳平衡。

英国的 COBOL 到 Java 迁移成本

成本在很大程度上取决于代码库规模、复杂度和方法。英国企业项目的指示性范围如下：

系统规模方法估计成本
小型（< 50,000 行）并行重写80,000 至 200,000 英镑
中型（50,000 至 500,000 行）绞杀榕200,000 至 800,000 英镑
大型（500,000+ 行）自动化 + 渐进式重构500,000 至 2,000,000+ 英镑
遗留大型机退役完整项目1,000,000 至 10,000,000+ 英镑

这些数字涵盖分析、迁移、测试和上线支持。它们不包括持续的运营成本、培训，以及常在项目中途浮现的下游集成工作。

Mecanik COBOL 到 Java 迁移服务 专注于英国企业迁移，涵盖评估、转换、数据访问层实现和输出对等性测试。对于权衡目标语言的组织，COBOL 迁移概览 列出了完整范围，包括 C#、Python、Go、C++ 和 Rust。对于从 IBM z/OS 迁出的项目，遗留大型机迁移服务 在代码迁移之外还涵盖基础设施退役。

主要风险及其管理方法

未记录的业务逻辑。 COBOL 系统承载着数十年间嵌入代码、没有外部文档的业务规则。发现并记录这些逻辑是任何迁移中最耗时、风险最高的部分。

数据访问层。 转换 COBOL 逻辑往往比替换其数据访问更容易。针对 DB2 的 EXEC SQL 和 VSAM 文件处理必须重新设计为 JDBC、JPA/Hibernate 或 Spring Data，这常常是最大的单项工作。

十进制精度。 每个 COMP-3 和 PIC 9 字段都必须以正确的刻度映射到 BigDecimal。在切换前用真实数据测试这些计算。

性能预期。 一个通宵处理 1,000 万 条记录的 COBOL 批处理作业设定了一个草率的 Java 重写可能达不到的标准。需要进行性能剖析和优化；JVM 一旦调优便表现良好。

回归测试覆盖率。 证明 Java 输出与 COBOL 一致的唯一可靠方法是使用真实（匿名化）数据进行全面的回归测试。在迁移开始前构建该测试套件。

切换风险。 在生产中切换到 Java 是风险最高的时刻。必须制定包含回滚和对账的详细切换计划。

关键要点

  • 凭借成熟的生态系统、强类型和深厚的开发者库，Java 是大型企业默认的 COBOL 迁移目标。
  • 将每个 COMP-3 字段映射到 BigDecimal，绝不映射到浮点基本类型；这是最常见的正确性失误。
  • 大多数英国企业项目采用绞杀榕方法配合选择性自动化。
  • 最大的风险是未记录的业务逻辑和数据访问层的重新设计；在迁移开始前解决这两者。

常见问题（FAQ）

为什么从 COBOL 迁移到 Java 而不是 C# 或 Python？ 对于已经在 JVM 上或已投入 Spring 和 Jakarta EE 的团队，Java 是自然之选。C# 适合处于 .NET 和 Azure 技术栈的组织，Python 适合那些优先考虑可读性和 AI 集成的组织。三者都是强大的企业目标。

Java 如何处理 COBOL 压缩十进制字段？ COBOL 的 COMP-3 和 PIC 9 十进制字段必须以匹配的刻度和精度映射到 Java 的 BigDecimal。这保留了精确的十进制算术。将它们转换为 double 或 float 会引入舍入误差，这是缺陷，而非捷径。

COBOL 逻辑能自动转换为 Java 吗？ 可以，借助工具。优秀的转换器能生成具有正确类结构、BigDecimal 映射和结构化异常处理的惯用 Java 17，并标记出嵌入式 SQL、CICS 调用和动态调用以供人工处理。数据访问层和业务校验仍是人工任务。

像 COMP-3 和 EBCDIC 这样的 COBOL 数据格式会怎样处理？ COMP-3 映射到 BigDecimal。EBCDIC 文本和定宽布局需要显式转换为 Unicode 和类型化模型，并在投入生产使用前用真实数据进行测试。

COBOL 到 Java 迁移需要多长时间？ 小型、文档完善的系统需要三到九个月。中型企业系统需要十二到二十四个月。大型大型机项目的完全退役可能需要三到五年。