This is the part that piqued my interest. I've seen cobol to java translated source, it looks like java used as an assembler for cobol. Certainly there's a spectrum of cobol-y-ness. One would be hard pressed to go from cobol to even a rudimentary class/domain business/presentation object oriented architecture, for example. Cobol control flow and data representations are simply to different. I'd like to see what they ended up with.
There are many many problems with these types of projects. One thing that often happens is leaving the new application in the hands of the legacy team to manage. They often lack even rudimentary skills in managing java runtimes. I saw one team struggle with performance issues that were easily solvable with a connection pool configuration change.
Maybe the worst case with these types of systems is enhancements going forward. You can guarantee there will be no more money spent on modernization, and any changes will be made to the Frankenstein java/cobol source. Which will continue to accrue technical debt and an even greater rate.
The main project I saw that did this was eventually abandoned, and luckily the cobol application was still running.
Certainly there's a spectrum of cobol-y-ness. One would be hard pressed to go from cobol to even a rudimentary class/domain business/presentation object oriented architecture, for example. Cobol control flow and data representations are simply to different.
It's still a win if they can go from procedural COBOL to procedural idiomatic Java.
I saw one team struggle with performance issues that were easily solvable with a connection pool configuration change.
Seen it happen before. Someone will step in and charge those hourly consulting fees.
You can guarantee there will be no more money spent on modernization, and any changes will be made to the Frankenstein java/cobol source. Which will continue to accrue technical debt and an even greater rate.
Not if the project includes a phase where they start modifying things to increase the degree of idiomatic Java code.
Seems like gotos would be fairly easy to clear out in the automated refactor. Control flow feels like one of the more trivial parts of automated refactoring, because that's straightforward AST modifications?
Control flow feels like one of the more trivial parts of automated refactoring, because that's straightforward AST modifications?
No. The AST part is wrong. Compilers do decompose code into basic blocks. Even the most spaghettified code decomposes into basic blocks. Any language with tail call optimization can handle the basic blocks rewritten as functions.
They spent 12 months making it less-COBOLy / autogenerated feeling