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.
Goto's and "fall through PERFORMS" make idiomatic java impossible.
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.
That won't get you to "clean" however.
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.