Thinking about automatic translation to Java? Think again

Is automatic translation to from COBOL to Java really all it’s cracked up to be?

In the quest to transform legacy applications into modern, web-based services, automatic translation from COBOL to Java is often touted as a fool proof way to quickly and efficiently modernize your system without sacrificing decades of programming investment.

At first glance, such a proposition seems entirely too good to be true. Is it really possible to automatically translate huge, complex, decades-old applications to Java while still retaining the same behavior and level of performance as the original code??

While companies selling these “fully-automated” services might like you to believe the hype, upon closer inspection, this rosy picture of push-button convenience starts to fade, and “too good to be true” becomes a very apt description indeed.

Language conversion is easy.?Good language conversion requires knowledge of the dark arts

In their review of language conversion, Terekhov and Verhoef quote a researcher from University of Twente, S.C. Sprong, who posted a very fitting description of the inherent difficulty present in any language conversion[1]:

“Low-level porting, even with provided documentation, is one of the blackest software arts; knowing how to do it well will surely get you a first-class ticket to hell.”

Though there might be some disagreement on exactly how complex automatic translation to Java is, many would agree that problems arising from discrepancies in behavior between the original and translated code, as well as issues related to overflow, type casting, and other complicated type manipulations[2] can most certainly cause delays in any automatic translation project, and that overcoming those difficulties will not only require extensive human intervention, but also produce atypical code that is much more difficult to maintain than handwritten Java.?Bottom line, unless you have a team of self-flagellating wizards that will enjoy the “challenge” of maintaining and tweaking the translated code, expect significant delays, cost overruns, and perhaps most importantly, a lack of enthusiasm for your project.

You still have to fine-tune the translated code by hand

“Automatic translation” is somewhat of a misnomer when we talk about translating COBOL to Java.?“Software-assisted” might come closer to what is actually taking place as a human engineer is very much involved in the modifications and refinement that happen post-translation.

Among the fine-tuning your engineers have to carry out, performance tuning is one of the most difficult and tedious, especially for large, complex applications.?Suganuma reports in his review of large-scale Java applications translated from COBOL that to make sure performance levels match those of the legacy application, engineers need to perform a significant amount of fine-tuning and adjustment after translation, which includes collecting and analyzing execution profiles for critical application scenarios, identifying performance bottlenecks, and making the necessary modifications to the translated programs.?Moreover, it’s not an uncommon occurrence where fixing one issue will cause issues elsewhere in the application, and it often takes a significant amount of fine-tuning to increase the performance of the translated programs to an acceptable level[3].

Guess what??Your Java programmers will still need to know COBOL

If you think that you’ll solve your mainframe labor shortage by simply automatically translating your legacy code to Java, you might want to take a step back and consider exactly how different working with Java translated from COBOL actually is.

An experience report that appeared at the IEEE International Conference on Software Maintenance and Evolution in 2018 describes an American newspaper company’s modernization project that migrated their business-critical IBM mainframe application to Linux servers by automatically translating the source code of the application from COBOL to Java[4].?Long delays and setbacks notwithstanding, they were finally able to deliver a functional, relatively stable translated version of their mainframe legacy application; however, new feature development remains a significant challenge as it requires in-depth knowledge of COBOL programming idioms and mainframe concepts that their Java software engineers simply don’t have. Consequently, they’ve had to spend time and resources cross training their developers in order to bridge that knowledge gap, which again adds an extra layer of complexity as well as cost.?Finally, in terms of new talent, they have had serious difficulty finding Java developers that are willing to work with the translated code due to its exotic and atypical nature.

Java translated from COBOL is more costly to maintain than handwritten Java software

The only thing that Java translated from COBOL has in common with handwritten Java is that they are both the same language.?The similarities end there.?Java that has been translated from COBOL is highly irregular and bloated both compared to the original COBOL code or a similar program written in Java by hand.?The size of the translated code can be as much as three times the size as the original COBOL code.?In one COBOL to Java translation project that actually succeeded, the 257,825 COBOL statements and 304,791 uncommented lines of code with 12,773 function-points were converted to 814,016 statements and 830,508 uncommented lines of code with 12,794 function-points—a code size increase of 272%[5].

Unsurprisingly, such a large increase in code volume carries much higher maintenance costs and requires a larger team of experienced developers who might be less than enthusiastic about working with spaghetti code.

COBOL-Java translators produce poor quality code

Not only is there code bloat with COBOL to Java translation, but there are serious issues with the resulting code quality as well.??According to Sneed in his field report on a successful COBOL to Java translation, the quality of the translated code is highly dependent on the quality of the original COBOL.?As a result, in order to successfully translate COBOL to Java, the source code must first go through an extensive, multi-step pre-processing procedure to improve the quality of the COBOL to the point that it is readable and machine processable[6].?With this kind of extensive reengineering as a prerequisite to begin the transformation to Java, we can already see that the amount of preparation and input required will result in higher cost and a longer project.?That’s before the post-processing and testing that must take place in order for the resulting applications to be functional, stable, and have the same level of performance as the original code written in COBOL.

Recompilation is the safest, fastest, and most effective way to migrate your code

With 20 years of experience in modernizing legacy systems, we understand that the safest, fastest, and most effective way to migrate your legacy applications off the mainframe is by directly recompiling your legacy source code on more modern, open platforms such as .NET or Linux.?Recompilation allows you to migrate your source code untouched and take a phased approach that will ensure the availability of your system during the entire period of your project.?Combined with full support for Docker and Kubernetes deployment, you can be sure that your migrated applications are fully cloud native and ready to meet your business needs.

References

[1] Terekhov, A. A. and C. Verhoef (2000). “The realities of language conversions.” IEEE Software 17(6): 111-124.

[2] Ibid.

[3] Suganuma, T., et al. (2008). Performance pitfalls in large-scale java applications translated from COBOL. Companion to the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications.

[4] De Marco, A., et al. (2018). COBOL to Java and Newspapers Still Get Delivered. 2018 IEEE International Conference on Software Maintenance and Evolution (ICSME), IEEE.

[5] Sneed, H. M. (2010). Migrating from COBOL to Java. 2010 IEEE International Conference on Software Maintenance, IEEE.

[6] Ibid.