Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • When they migrate to Java how are they migrating things like the messaging (send, receive) functionality?
    by mpfh
  • I just asked Google AI how LLMs translate COBOL code containing GOTOs into Java, a language that doesn't have GOTO. It gave several examples, one of them being this:

    COBOL code:

      PROCESS-DATA.
      ADD 1 TO COUNTER.
      DISPLAY COUNTER.
      IF COUNTER < 10 GO TO PROCESS-DATA.
    Java translation:

      while (counter < 10) {
    counter++;
    System.out.println(counter);
  }
    If "counter" is 10 on entry, the COBOL code prints 11 while the Java code prints nothing. So not only keeping old bugs, but apparently introducing new ones too!

    I wrote COBOL code for a few years at a job when I was a teenager. What makes legacy COBOL code difficult IMO is it can sometimes be very hard to maintain a mental execution state when examining the code, for several reasons:

    1. all variables are global, aka, WORKING-STORAGE. You list all the variables used in the program and they are accessible to the entire program.

    2. programs are divided into paragraphs. Control normally flows sequentially top to bottom through paragraphs, one executing after another. Except that the PERFORM statement can drastically alter this normal flow control, and you can't tell by looking at a paragraph how it will be executed. To do that, you have to look at all PERFORM statements that mention this paragraph or any paragraph physically before it, because in COBOL you can say PERFORM PARA1 THROUGH PARA27. If PARA13 is physically between PARA1 and PARA27, it's potentially going to get executed.

    3. In true legacy COBOL, before structured COBOL was a thing (circa 1985), the main control flow statement in addition to PERFORM was GOTO. Lots of flag setting, and lots of GOTOs. So in the previous example, you can't tell if PARA13 is going to get executed because any prior statement might be a GOTO PARA14, skipping execution of PARA13. But even worse, you are still under the influence of the PERFORM THRU, so after PARA27 is executed, control returns to the statement following the PERFORM THRU, wherever that was. But if you GOTO PARA27, without being under a PERFORM THRU, then PARA27 is executed followed by the next sequential paragraph. Trying to figure this out statically by looking at the program can be very difficult, especially considering PERFORMs that are nested at runtime but may not be anywhere near each other in a code listing.

    by prirun
  • As I understand it, the translation isn't done by an LLM but by a deterministic AST-based migrator. Also, carrying over the bugs is the stated goal.
    by aldente0630
  • How does ai implement all the not Cobol parts a Cobol program rely on? Job Contol, CICS, sort processors? Cobol and mainframe technologies are non existant in java on any modern machine
    by Surac
  • For the article they just mocked it out for unit tests. But in reality you really can't - that’s a massive pain in the ass. Rewriting pure math is easy, but mocking CICS transaction isolation in java means spinning up these monstrous adapter frameworks that just tank performance
    by TimByte
  • If the systems are to stay on mainframe/micro land, all IBM, Fujitsu, Unisys platforms support Java.

    This is one set of ecosystems, where .NET going cross platform still misses out to Java, and neither of those companies cares about supporting it on their platforms.

    There are some half way supported Python, Go and Rust versions as well, although I think they need the "WSL" of the respective mainframe/micro OS, aka UNIX services.

    by pjmlp
  • Batch job control is handled by alternative systems (already often triggering the work on mainframes anyway) like Control-M

    CICS is the big issue but AFAIK there were attempts. Everything else, including sort and VSAM, has various options provided usually by COBOL compiler vendors.

    by p_l
  • While not everything can be easily converted (IMS, CICS, reports, batch processing etc.), there are many situations where automated tooling can be helpful in migrations.

    Related to this, I created a tool for situations where you want to compare COBOL code with Java code. It includes a preprocessing step where IMS etc. calls are converted to mocks that return JSON (from file), and also use JSON for input/output, and GnuCOBOL to run the program. More a proof-of-concept than production, but here is a link if somebody finds it helpful.

    https://github.com/mikko-ahonen/coboltwin

    by kukkeliskuu
  • Why should I convert COBOL to Java? LLM can write COBOL just as fine.
    by mtct88
  • yes i was wondering the same... what's wrong with COBOL? especially in an era of LLM... also, i find COBOL to be way more readable and intuitive than Java.
    by kome
  • Because humans don't want to spend time to learn how to use "dead" languages and humans still play a role in programming. Having LLMs churn out more COBOL instead of Java means more of the code base becomes 'terra incognita' for the involved humans. Learning COBOL isn't that hard - which was one of its stated purposes - but it is still seen as decidedly 'uncool' and 'legacy'. Maybe the increased role of LLMs in coding will change this and make coding in 'legacy' languages 'cool' again just like e.g. the availability of accurate time sources like mobile devices made mechanical watches trendy again or the direct access to music through streaming services made vinyl and now CDs (i.e. 'physical media') regain market share.

    Maybe.

    Still not something you want to risk your business on.

    by Leonard_of_Q
  • Stuff like this are already a commercial product, it isn't only Zig to Rust rewrites going around.

    https://www.pega.com/insights/resources/break-free-legacy-ma...

    https://www.ibm.com/products/watsonx-code-assistant-z

    https://global.fujitsu/en-global/pr/news/2026/03/30-01

    https://www.rocketsoftware.com/en-us/insights/ai-powered-cob...

    by pjmlp
  • I remember a similar story shared this year at JAX2026 from the Sparkasse Group, they said they were using AI to migrate from COBOL, but they still were in the middle of the migration. Maybe they faced the same issues / problems? It seemed pretty zealous to me, that everything was working smoothly, but this article highlights the limitations
    by madduci
  • some years ago I talked to a software engineer at a bank, he said it would be too risky for them to move away from the mainframe what with regulations and all, I'm not sure if AI could make the banks more risk friendly, so if Sparkasse does that already, I, for one, am eager to learn the result (and am happy to have no account there)
    by wolfi1
  • This sounds like what the company Mechanical Orchard offers: https://www.mechanical-orchard.com/

    Their pitch is like, "we take your COBOL code, and all the real-world data you can give us. Then we model your COBOL program as a graph, where each node has inputs and outputs. Then we use AI to port each node, making sure that it has the same (input => output) mapping for all the test data you gave us."

    by Taikonerd
  • > for all the test data you gave us

    This is the secret sauce. You'll be responsible for any defects if you didn't prepare your test data to act like a massive unit test. Wonder how hard is to prepare the ideal test data vs writing the unit tests themselves in COBOL and verifying their translation. I guess if you throw enough data at it, the effort is minimal while the coverage becomes good enough to fix any bugs manually.

    by ASalazarMX
  • The largest test case was 4kloc.

    There are hundreds of billions of lines of cobol in production.

    The IRS alone has approx 160 cobol programs, averaging 230kloc each.

    by pacaro
  • The biggest problem is not that bugs are migrated with COBOL, but that lots of new bugs are going to be introduced. AI is not deterministic, it will be making tons of mistakes. The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools. However, it requires much more time as each step must be prompted, tested and committed manually. Any hope that one-shot migraton of a large code base will not introduce enormous number of bugs is very naive. LLM is very bad on handling long context - it is their nature unfortunately. There is no answer to this problem yet.
    by toplinesoftsys
  • AI doesn't need to be deterministic.
    by Yopolo
  • > The only realistic low-error approach is incremental step-by-step migration using Cursor or similar tools.

    Correction: AI is not deterministic, the only realistic low-error solution is not a more complex use of non-deterministic AI, but deterministic transpilation.

    The problem is that this results in COBOL-in-Java which runs correctly but it is a nightmare to maintain.

    by dragonwriter
  • You don’t need the entire codebase in context in every moment to migrate it. Also AI being non deterministic does not prevent it from one-shotting perfect solutions 100% of the time for simple enough problems. And every model generation brings this bar higher. So that’s really not a fundamental problem. And we can also implement llm inference deterministically if we want, it’s just that it’s not worth the loss in performance to do it.
    by JV00
  • > AI is not deterministic, it will be making tons of mistakes.

    Most compilers are also not deterministic, at least by default, but they don't usually make mistakes. Determinism isn't an important quality here. And if it were, AI can be deterministic, it just isn't normally for much the same reason compilers typically aren't (hint: performance).

    I find it bizarre that I keep reading this here. Just one of those things that keeps getting blindly repeated without receiving any thought?

    by win311fwg
  • If a considerable size of test data is available for any system, rewriting a well-understood one is much easier today than rewriting by hand. The issue is mostly with the “well-understood” part, as over the years, none cared about understanding and it became a working blackbox that is responsible for a critical part of large system and none wants to take the risk.
    by codetiger
  • > AI is not deterministic, it will be making tons of mistakes.

    Just set the sampling temperature to zero and remove any unintended non-determinism during the parallel computation of the token probability distribution. The problem is solved? Of course, not. Non-determinism has little to do with LLMs' mistakes.

    by red75prime
  • > AI is not deterministic, it will be making tons of mistakes.

    From the paper:

    > The COBOL source is passed through an internal deterministic Migrator to produce a generated Java target.

    Also, humans are not deterministic either. Give the same COBOL -> Java translation to multiple developers and each will come up with a different solution. Heck, even the same developer will produce a different output for the same task, depending on the day of the week.

    by selcuka
  • Before, only the senior cobol programmers at the company understood and knew the codebase.

    Now, no one does.

    I can see the allure of moving away from a legacy cobol system. But an AI rewrite doesn't actually solve any of the issues with having a legacy cobol codebase. You just have a new system no one knows or understands.

    by matsemann
  • Having worked in COBOL extensivly in the 80s and 90s, as well as working for a software house that did migrations (Craziest was Plan assembler to Dec Vax C).

    I do wonder how an ambitious AI would handle the maths. COBOL is renowed for its fixed no rounding maths, utterly rigid and defined in the code, Java on the other hand is not (e.g., 0.1 + 0.2 becomes 0.30000000000000004), unless they are extensivly using BigDecimal, then its already a broken migration.

    I've seen projects proclaim in the past to migrate COBOL systems to Java, and fail expicly when the solution was a dtaawarehouse system and a seperate Java system using the legacy backend to do all the fancy marketing reports or whatever other department was pushing for changes they wanted without a grasp of what it truly entailed and blinded by some sales pitch.

    It's not just the code that needs migrating, its the data as well, then you want solid robust infrastrucure, which is why IBM still sell those mainframes to run all that well battle tested COBOL code.

    Is it impossible to migrate to Java or any othger language - no, anything can be done, but the level of devil in the details and not just software, the data and a robust system to run it upon. It is very easy for even the best to overlook a gotcha.

    We have all used an AI where it has gone down one path and you then point out something and it corrects itself, without the knowledge and a load of old grey beads(or a team) to act as devil advocate and try to pull the output apart, YOU can end up with something that works for everyones satisfaction, but is hiding a few gotchas down the line. AI coding needs a full debate team with one puishing it and one countering it almost I'd say.

    If it works, why change it is always a good approach and why we mostly have in certain systems a COBOL backend with APIs or datawarehousing to expose for fancy java or other language added value/functionality.

    I can only image generations of directors pushing cutting edge to replace legacy systems, and learning that cutting edge can cut you. My sympathy for the IT departments who have to deal with that as it has always been a bain of IT departments who are then forced to justify why it's fooling in a constructive way and explain it to non IT people in upper managment why the case.

    As for migrating COBOL to anything, I'd not do it myself, id suggest a rewrite/redesign of a new system from scratch and then run both in parallel for a long time and make sure they actually do the same job and results. Even hand migrating back in the day, would produce a lot of messy code that refactoring would make sence and yet, not what the client would pay for as that would be a rewrite.

    by Zenst
  • > Now, no one does.

    Not true, AI does. It's AI job security...

    by js8
  • If you can migrate using a strangle pattern, I can see it working pretty well and fast.
    by remify
  • "Now, no one does."

    well, we just need to learn the rewrite then ???

    by tonyhart7