撰稿 | 千山

審校 | 云昭

在編程語言中，COBOL 絕對算得上是“上古神獸”，可以追溯到1959年左右，目前全球仍有眾多大型企業或政府機構用的是COBOL 編寫的舊軟件。但因為太過古舊，很多新手開發者甚至聞所未聞。

為了解決COBOL應用程序現代化的問題，IBM最近推出了IBM Z 服務，意在利用 AI 技術將COBOL 代碼轉譯成 Java 語言。

1、骨灰級語言迎來新生機

COBOL這門語言雖然古老，但生命力驚人。根據2022年的一項調查，生產系統中使用的COBOL代碼超過了8000億行。但問題在于，COBOL 的存在已逾一個甲子，很多編寫應用程序的開發人員早已退休甚至離世了。

正因為“懂COBOL”的程序員極為稀缺，所以他們的薪水是相當可觀的，甚至連美國政府都曾經公開招募COBOL程序員，以便維護那些還在運轉中的眾多關鍵任務應用程序。

無論從可操作性還是效率來說，COBOL在當下都過時了，但正是由于COBOL專家的數量極少，這也導致“遷移”往往成為一個復雜昂貴的命題。2012年，澳大利亞聯邦銀行下決心更換了其核心COBOL平臺，這場改造耗時5年，耗資超過7億美元。

在這一背景下，IBM發布了IBM Z的Code Assistant，它使用代碼生成AI模型將COBOL代碼轉換為Java。

IBM介紹，用于 Z 大型機的 watsonx Code Assistant 旨在幫助開發人員評估和確定最需要現代化的代碼，使他們能夠更快地更新大型應用程序，專注于關鍵任務。

Omdia 首席分析師 Roy Illsley對此評論道，將代碼遷移到 Java 意味著可以找到更多的程序員來做支持，如果 COBOL 應用程序在Z大型機上的 Linux 系統中運行，那么它們將來可能更容易地從大型機上遷移下來(盡管這并不總是像看起來那么容易）。

據悉，IBM Z的Code Assistant將于今年第四季度上市，在此之前，IBM 會在今年9月初于拉斯維加斯舉行的TechXchange會議上演示該功能。

2、轉換成Java，代碼高度自然

那么IBM Z服務到底是如何發揮作用的呢？

IBM研究院首席科學家Ruchir Puri在接受外媒采訪時表示：“IBM建立了一個新的、最先進的生成人工智能代碼模型，將遺留的COBOL程序轉換為企業Java，生成的代碼具有高度的自然性。”

為幫助企業重構其大型機應用程序，IBM Z的Code Assistant可以在本地配置中運行，也可以作為托管服務在云中運行，由代碼生成模型CodeNet提供支持。

Puri提到，CodeNet 模型使用1.5萬億個參數進行訓練，擁有 200 億個參數，設計了一個大的上下文窗口(32,000個令牌)，以“捕獲更廣泛的上下文”，實現“更有效的COBOL到Java轉換”。

放眼當前市場，將COBOL應用程序轉換為Java語法的自動化工具并不少見。Puri也承認這一點。他進一步指出，Code Assistant采取措施避免犧牲COBOL的功能，同時降低成本并生成易于維護的代碼，這就區別于市場上的一些同類競品。

因為有些類似的產品主要是針對COBOL 代碼進行靜態和動態分析而不是運用AI，究其根本，它們只是將代碼拆分為仍然基于 COBOL 的微服務。

watsonx Code Assistant for Z 生成的 Java 代碼將是面向對象的，但仍會與 IBM 聲稱的 COBOL 應用程序的其余部分以及 CICS、IMS、DB2 和其他 z/OS 運行時等關鍵服務進行互操作。

“IBM為IBM Z構建了代碼助手，以便能夠混合和匹配COBOL和Java服務，”Puri說。“如果系統的‘理解’和‘重構’功能建議應用程序的給定子服務需要保留在COBOL中，那么它將保持這種方式，而其他子服務將轉換為Java。”

但這并不是等于說IBM Z的服務是完美無瑕的。斯坦福大學最近的一項研究發現，使用類似于它的代碼生成人工智能系統的軟件工程師更有可能在他們開發的應用程序中造成漏洞。實際上，Puri警告不要在由人類專家審閱代碼之前部署由Code Assistant生成的代碼。

3、轉換成Java的影響：風險與垃圾代碼

“像任何人工智能系統一樣，企業的COBOL應用程序可能有獨特的使用模式，而IBM Z的Code Assistant可能還沒有掌握這些模式。”“必須用最先進的漏洞掃描儀掃描代碼，以確保代碼的安全性。”Puri如是說道。

事實上，也有開發人員對AI生成的代碼的不可控性提出了質疑。在Reddit論壇的相關討論中，有網友指出：“在某些時候，我們無法知道人工智能的下一個動作，到底是處于天才還是愚蠢的決策。”

“有些東西我們可以理解和單元測試，但在更大的規模上，系統非常復雜，有很多細微差別和級別，以至于沒有一個人知道每個設計決策的‘原因’。”

還有人直接提出，“Java真的是這里最好的選擇嗎？”對此，有人表示理解，認為選擇Java是個務實的決定。“Java是選項，因為IBM大型機有一個JVM。因此，從通過 CICS 運行 COBOL 過渡到運行 Java 是相當無縫的。特別是使用 IBM 的 Rational Developer 工具集。”

但也有人提出異議。“最大的問題是Java和COBOL的結構完全不同，因此機械翻譯往往會產生完全的垃圾。認為它是一個好的候選者的唯一原因是因為你也沒有實際編程的經驗。所以……很大程度上是一個管理決策。”

不過，開發者們多數還是認為，Java擁有強大的企業影響力，并且已經在遺留環境中采用多年，所以考慮用它進行遷移并不令人驚訝。

IBM對這類爭論應該也有所預料，因此該公司也表示watsonx Code Assistant產品組合將在未來擴展到其他編程語言。

4、COBOL二度出圈，不遠了

撇開風險不談，在IBM看來，像Code Assistant這樣的工具對其未來的發展至關重要。今天，大約84%的IBM大型機客戶運行COBOL——主要是政府部門和金融業的客戶。雖然IBM的大型機部門仍然是其整體業務的很大一部分，但該公司將大型機視為通往廣闊的、有利可圖的混合計算環境的橋梁。

尤其再這樣一個代碼生成AI工具的時代，許多類Copilot的工具已經問世。早前，GitHub Copilot和亞馬遜CodeWhisperer等工具的出現打響了競逐的號角。藍色巨人當然不能示弱。今年5月，IBM在其Watsonx人工智能服務中推出了fm.model.code，該服務為沃森代碼助手提供支持，允許開發人員在程序(包括紅帽的Ansible Lightspeed)中使用簡單的英語提示生成代碼。

如今IBM Z服務的推出，顯而易見是在AI編碼助手領域針對Z大型機的針對性優化。可以想象通過這樣的方式，COBOL的應用前景會更加的擴大，Java技術棧的開發者也許再也不用看見這個晦澀的老語種避而遠之了。

同時，未來IBM是否將加速產品上市時間并繼續擴大技能庫，相信不久就會有答案。

參考鏈接：

https://techcrunch.com/2023/08/22/ibm-taps-ai-to-translate-cobol-code-to-java/

https://www.theregister.com/2023/08/22/ibm_says_genai_can_convert/

https://www.reddit.com/r/programming/comments/15z7j1u/ibm_taps_ai_to_translate_cobol_code_to_java/