Experience on Automatically Converting a C++ Monolith to Java EE

This paper details the experience and techniques involved in automatically converting an 800,000-line C++ monolith into a Java EE application running on WildFly, addressing specific architectural challenges and utilizing a clang-tool-based solution to continuously regenerate Java code alongside ongoing C++ development.

Andre Vehreschild, Lexi Pimenidis

Published Tue, 10 Ma
📖 5 min read🧠 Deep dive

Imagine you have a massive, 80-year-old mansion built entirely of stone and mortar (the C++ Monolith). It's sturdy, it works, and it houses 800,000 bricks (lines of code). But the owners want to move everyone into a sleek, modern glass skyscraper (the Java EE Application Server).

The problem? You can't just pick up the stone bricks and drop them into the glass building; they won't fit, and the glass building has different rules about how things are built. Plus, the family is still living in the stone mansion, adding new rooms and fixing leaks every day while you try to move them.

This paper is the story of how two architects (the authors) built a robotic construction crew (a software tool called a "transpiler") to automate this impossible move. Here's how they did it, explained with some everyday analogies.

1. The Challenge: Why Not Just Hire a Human?

If you tried to hire a human to move 800,000 bricks from stone to glass, it would take forever. They'd get tired, make mistakes, and by the time they finished the first room, the stone mansion would have changed again.

  • The Solution: They built a robot (using a tool called Clang-Tool) that reads the stone blueprints and instantly draws the glass blueprints. It's fast, consistent, and never gets tired.

2. The "Inheritance" Problem: The Double-Duty Employee

In the old stone mansion, some employees had two bosses at once (Multiple Inheritance). In the new glass skyscraper, an employee can only have one direct boss, though they can join many clubs (Interfaces).

  • The Fix: The robot had to be clever.
    • Scenario A (The Database Employee): If an employee was reporting to a "Manager" and a "Database Clerk," the robot decided: "Okay, you're still the Manager's employee, but now you carry the Database Clerk in your pocket." Instead of being the Clerk, you just have a Clerk.
    • Scenario B (The Chain of Command): If an employee was part of a "Chain of Command" (a line of people passing a message), the robot changed the rules. Instead of the employee walking down the line, a "Manager" now calls them one by one. It's like changing from a relay race where runners pass the baton, to a coach calling players to the field one by one.

3. The "Enum" Problem: The Color Code

In the old mansion, colors were just numbers. You could say "Red is 0," but you could also tell the system "Red is 42" (even though 42 isn't a color), and the system would just shrug and say, "Okay, sure."
In the new glass building, the rules are strict. "Red" is a specific object. You can't just assign it the number 42.

  • The Fix: The robot turned every "number-color" into a tiny, custom-made box.
    • It created a special box for "Red" that holds the number 0.
    • It added a safety guard: If someone tries to put the number 42 into the "Red" box, the robot throws a tantrum (an error) immediately, rather than letting the building collapse later.

4. The "Stream" Problem: The Conveyor Belt

The old system wrote messages on a long conveyor belt (Streams), adding items one by one: "Hello," then a comma, then "42."
The new system prefers to write the whole sentence on a piece of paper at once.

  • The Fix: The robot learned to grab the conveyor belt items and glue them together into a single sentence using a "StringBuilder" (a magical notepad) before writing it down. It also learned to spot when the old system said "End of line" and made sure the new system hit the "Enter" key correctly.

5. The "Destructor" Problem: The Self-Cleaning Room

In the stone mansion, when a worker left a room, they automatically turned off the lights and locked the door (Destructors).
In the glass skyscraper, workers just vanish, and a janitor (Garbage Collector) comes by much later to clean up. This is risky if you were holding a heavy key (a database connection) that needed to be returned immediately.

  • The Fix: The robot introduced a "Try-with-Resources" rule. It's like putting a worker in a special booth. As soon as they step out of the booth (finish their task), the door automatically locks and the lights turn off, no matter how they left (whether they finished happily or ran away in a panic).

6. The Result: A Successful Move

The robot didn't get it 100% perfect immediately. There were about 10 tricky rooms where the robot got confused.

  • The Strategy: The team let the robot do 99% of the work. For the 1% that was wrong, they set up a "Checklist." Every time the stone mansion changed, the robot re-drew the glass plans. If the checklist flagged a known tricky room, a human stepped in to fix it manually.
  • The Outcome: Over time, the number of errors dropped like a stone falling down a well. Eventually, they had only about 60 tiny errors left. They fixed those by hand, turned on the lights in the glass skyscraper, and it worked perfectly.

The Big Takeaway

You can't just copy-paste code from one language to another; you have to translate the logic and the culture of the building. By using a smart robot to do the heavy lifting and keeping humans in the loop for the tricky parts, they successfully moved a massive, living system from the Stone Age to the Modern Age without stopping the business for a second.