What I'm trying to say is that with COBOL, the hard part is stasis and the reason isn't COBOL, but the legacy context in which COBOL is still present. For year

What I'm trying to say is that with COBOL, the hard part is stasis and the reason isn't COBOL, but the legacy context in which COBOL is still present. For years, software has been migrated away from COBOL. Starting afresh, re-implementing, manual translation, transpiling. What remains, is there because it works and no one want to touch it. If there would exist a reliable, risk free migration path to generate Java code, I'm sure that is not the situation we're talking about. There are always risks and that's where the paperwork comes in. I've done my share of porting Pascal to C or transpiling 4D into C++. Lua to Python. Given the right tools, it is usually not the tedious translation task but the lack of automated tests, foreign function interface calls, archaic hardware quirks, event orders and real-time constraints that are causing the issues. Not sure and LLM is very helpful here. Even if it's incredibly clever in producing Java from COBOL 99% of the time, the paperwork is only about the 1% of errors it may introduce. Absent a formal, exhaustive validation of the LLMs's capabilities its contribution basically comes down to a huge code review for a pull request of unknown origin.