撰稿 | 千山

审校 | 云昭

在编程语言中，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/