IBM plans selective COBOL-to-Java conversion

IBM plans to use generative AI to help developers turn selected COBOL business services into Java without replacing an entire mainframe application. Its 22 August announcement of watsonx Code Assistant for Z describes a staged modernisation process, with a preview planned for September and general availability expected in the fourth quarter of 2023.

File photo: Infopark IBM building, sign, 2016 Budapest, by Globetrotter19. Cropped and resized; this photo adaptation is available under CC BY-SA 3.0.

The distinction matters: changing a programming language isn’t necessarily the same project as moving an application off IBM Z. IBM is designing the generated Java to work alongside remaining COBOL code and existing mainframe services. The proposed product is a way to change parts of an application while retaining its operating environment.

Choose the service before translating it

IBM expects the workflow to begin with Application Discovery and Delivery Intelligence, its inventory and analysis tool. Developers would then refactor COBOL business services, transform selected code into Java and validate the result, including through automated tests. Translation comes after understanding and separating the relevant business function, rather than being the first step applied to every line.

In an interview with TechCrunch, IBM Research chief scientist Ruchir Puri said the system could recommend leaving some services in COBOL while converting others. IBM’s announcement also describes intended interoperability with CICS, IMS, Db2 and other z/OS runtimes. Taken together, those details point to a mixed-language application, not an automatic all-Java replacement.

IBM says it wants object-oriented Java that developers can maintain, rather than COBOL syntax expressed in another language. That’s an intended outcome, not a demonstrated guarantee for every customer’s code. Puri cautioned that human experts should review generated code before deployment and that it should undergo vulnerability scanning.

Testing still has a separate job

The sequence leaves developers with two separate questions: does the transformed service preserve the required behaviour, and is the resulting implementation safe to deploy? Producing Java syntax doesn’t answer either question by itself. IBM’s proposed automated testing and Puri’s call for expert review are different safeguards, not evidence that every business rule, unusual input or integration dependency will be handled correctly.

IBM also points to Java performance on its hardware, but the supporting footnote needs careful reading. Its example of up to 70% higher throughput per core compares a particular business-rules workload on IBM z16 with a specified x86 server, using named Java runtimes and configurations. It isn’t a measurement of code produced by this new assistant, a COBOL-to-Java conversion accuracy rate or a general promise of a 70% application speed increase.

The announcement describes a 20-billion-parameter code model trained on 1.5 trillion tokens. Those scale figures likewise don’t answer how reliably it will translate a particular production application. IBM identifies the token count as based on proprietary internal data; the announcement doesn’t provide an independently reproducible end-to-end migration benchmark.

Availability is still a plan

IBM plans to preview the assistant at TechXchange in September before the fourth-quarter release. Its notice says future plans can change or be withdrawn and shouldn’t be used to make a purchase decision. For teams assessing the proposal now, the useful dividing line is between the workflow IBM intends to support and the results they would still need to validate on their own code.