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 遷移需要多長時間？ 小型、文件完善的系統需要三到九個月。中型企業系統需要十二到二十四個月。大型大型主機專案的完全退役可能需要三到五年。