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

Dit rapport beschrijft de ervaringen en technieken bij het automatisch converteren van een 800.000 regels tellende C++ monoliet naar een Java EE-architectuur, inclusief het oplossen van veelvoorkomende taalverschillen en het gebruik van een clang-tool voor continue regeneratie van de code.

De kern

Van Steenrots naar Moderne Stad: Het Verhuizen van een C++ Reus naar Java

Stel je voor dat je een gigantisch, oud kasteel hebt gebouwd van zware, onhandelbare stenen (dit is de C++ code). Dit kasteel is 800.000 stenen groot en bevat alles wat een bedrijf nodig heeft: van de kelder tot de toren. Het werkt prima, maar het is zwaar, moeilijk te verbouwen en er zijn maar weinig metselaars die er nog mee kunnen werken.

Het bedrijf besloot: "We verhuizen naar een moderne, flexibele stad van glas en staal (Java)." Maar er is een probleem: ze willen niet wachten tot het kasteel leeg is. Ze willen terwijl ze nog in het kasteel wonen en dagelijks nieuwe kamers bouwen, het hele gebouw automatisch verplaatsen naar de nieuwe stad.

Dit paper vertelt het verhaal van hoe twee ingenieurs (Andre en Lexi) een automatische robot bouwden om deze taak te volbrengen.

1. De Uitdaging: De "Vertaal-Robot"

Normaal gesproken zou je een team van mensen moeten inhuren om elke steen handmatig te verplaatsen. Dat zou jaren duren en vol fouten zitten. Dus bouwden ze een software-tool (een "transpiler") die de C++-stenen leest en ze direct omzet in Java-glas.

De robot werkt als een super-snel vertaalprogramma, maar dan voor bouwwerk. Hij kijkt niet alleen naar de woorden, maar ook naar de structuur.

2. De Grote Hindernissen (En hoe ze ze oplosten)

Tijdens het verhuizen botsten ze op drie grote obstakels, die ze met slimme trucs oplosten:

A. De "Twee Vaders" Probleem (Meerdere Inheritance)

• Het probleem: In het oude kasteel (C++) mocht een kamer (een klasse) twee verschillende vaders hebben (erf van twee klassen tegelijk). In de nieuwe stad (Java) mag een gebouw maar één vader hebben.
• De oplossing: De robot keek naar de vaders.
  • Als één vader een "Database-bewaker" was, veranderden ze de relatie. In plaats van "Ik ben een bewaker" (erfenis), werd het "Ik heb een bewaker" (een vriend in huis).
  • Als één vader een "Commando-lijn" was, bouwden ze een nieuwe deur. In plaats van dat de kamer zelf de lijn doorliep, gaf hij de controle door aan een manager die de lijn regelde.
  • Voor de lastige gevallen (waar de robot niet uitkwam) lieten ze een paar mensen handmatig de stenen verplaatsen.

B. De "Stream" van Water (Invoer/Uitvoer)

• Het probleem: C++ schrijft tekst alsof het water door een buis stroomt (cout << "Hallo" << 42). Java doet dit anders; het plakt stukken papier aan elkaar.
• De oplossing: De robot zag de waterpijp en vervangde die door een plakmachine (een StringBuilder). Hij plakte "Hallo" en "42" netjes aan elkaar en zette ze in een envelop. Als er een knopje "Nieuwe regel" (endl) werd gedrukt, zorgde de robot dat de envelop gesloten werd en de volgende regel begon.

C. De "Vage Kleuren" (Enums vs. Getallen)

• Het probleem: In C++ mag je een kleur (zoals "Rood") zomaar als een getal behandelen. Je kunt een kleur "42" noemen, zelfs als dat niet bestaat. Java is streng: een kleur is een object, geen getal. Als je probeert een kleur als getal te gebruiken, schreeuwt de computer "Fout!".
• De oplossing: De robot bouwde voor elke kleur een kleine doos (een klasse).
  • Hij maakte een sleutelgat voor het getal (zodat je de kleur kunt omzetten naar een nummer).
  • Hij maakte een slotje (zodat je niet zomaar een willekeurig getal in de doos kunt gooien).
  • Zo bleef de logica hetzelfde, maar was het veilig voor de nieuwe stad.

D. De "Verdwijnde Sleutels" (Constructors en Destructors)

• Het probleem: In het oude kasteel hadden de kamers een "deurwachter" (destructor) die zorgde dat de lichten uitgingen en de ramen sloten als je de kamer verliet. Java heeft geen deurwachters; het vergeet de kamer gewoon en laat de brandweer (de Garbage Collector) er later wel achter komen.
• De oplossing: Ze gebruikten een nieuwe techniek uit Java genaamd "Try-with-resources".
  • In plaats van te hopen dat de deurwachter komt, zetten ze een automatische afsluitklep in de deur. Zodra je de kamer verlaat (of als er brand uitbreekt), sluit de klep automatisch. Zo gaan de dure bronnen (zoals database-verbindingen) nooit verloren.

3. Het Resultaat: Een Geslaagde Verhuizing

De robot werkte niet perfect. Aan het einde waren er nog ongeveer 60 stenen die niet helemaal goed pasten. Maar dat is heel weinig voor een gebouw van 800.000 stenen!

• De leercurve: In het begin vielen er veel fouten. Maar zodra ze de "Java-type-systeem" (de strenge regels voor kleuren en getallen) in de robot stopten, daalde het aantal fouten drastisch.
• De uitkomst: Het bedrijf had nu een werkend Java-systeem dat op een moderne server (WildFly) draaide. Ze konden verder bouwen in Java, terwijl de oude C++-code nog steeds bestond (voor de zekerheid).

Kortom: Het paper laat zien dat je een gigantisch, oud systeem niet handmatig hoeft te slopen om het nieuw te maken. Met de juiste robot (software-tool) en slimme aanpassingen voor de verschillen tussen de oude en nieuwe wereld, kun je de verhuizing succesvol en veilig uitvoeren.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Experience on Automatically Converting a C++ Monolith to Java EE" in het Nederlands.

Probleemstelling

Het paper beschrijft de uitdagingen en de aanpak bij het converteren van een groot C++ monolithisch systeem (ongeveer 800.000 regels code, 2.500 bestanden, 3.000 klassen) naar Java. De organisatie wilde niet alleen de programmeertaal wijzigen (van C++98 naar Java 8), maar ook de architectuur transformeren van een standalone server naar een applicatie die draait op een Java Application Server (WildFly).

De belangrijkste obstakels waren:

1. Grootte en continuïteit: De C++-codebase was actief in ontwikkeling (bugfixes, nieuwe features) tijdens het conversieproces. Een handmatige conversie was te tijdrovend en foutgevoelig.
2. Architectuurverschillen: De overgang van een monoliet naar een server-gebaseerde architectuur vereiste fundamentele veranderingen in hoe objecten worden beheerd en hoe fouten worden afgehandeld.
3. Taalspecifieke verschillen: C++ en Java hebben ingrijpende verschillen in functionaliteit, zoals:
   • Meervoudige erfenis (multiple inheritance) vs. enkelvoudige erfenis met interfaces.
   • Enums die in C++ als integers fungeren, terwijl Java strikte enum-types heeft.
   • Destructors en RAII (Resource Acquisition Is Initialization) voor resource-beheer, wat in Java ontbreekt.
   • Stream-based I/O en uitzonderingsbeheer.
4. Gebrek aan geschikte tools: Bestaande conversietools werden als te inflexibel beoordeeld voor deze specifieke casus.

Methodologie

De auteurs ontwikkelden een geautomatiseerde transpiler (transformatiecompiler) gebaseerd op het LLVM/Clang-toolkit. De aanpak was als volgt:

• Architectuur van de Transpiler:

  • De tool is geschreven in C++ en gebruikt de Clang AST (Abstract Syntax Tree) om de C++-code te parsen.
  • Het systeem gebruikt een Visitor-pattern (ConstDeclVisitor, ConstStmtVisitor, TypeVisitor) om de AST te traverseren.
  • Een Rewriting Visitor voert diepere analyses uit en optimaliseert de output.
  • De generatie van Java-code gebeurt via een Template Engine. C++-constructen worden gemapt naar Java-templates. Bijvoorbeeld, een cast-expressie in C++ wordt gemapt naar een specifieke Java-template met placeholders voor type en expressie.

• Type- en Package-Beheer:

  • De tool bouwt een symbolenregister op om C++-types naar Java-types te mappen. Dit is cruciaal om onnodige casts te voorkomen en de leesbaarheid te waarborgen.
  • In plaats van #include-bestanden direct om te zetten naar import-statements, koppelt de tool symbolen aan Java-packages op basis van conventies (bijv. voorafgaande letters in klassenamen).

• Iteratief Proces:

  • Omdat de C++-ontwikkeling doorging, werd de transpiler geïntegreerd in het build-systeem. Bij elke commit werd de C++-code automatisch geconverteerd.
  • Een "checked replace"-mechanisme werd gebruikt: als de gegenereerde Java-code overeenkwam met een bekende foutpatroon (template), werd het bestand vervangen door een handmatig gecorrigeerde versie.

Kernbijdragen en Oplossingen voor Uitdagingen

Het paper beschrijft specifieke technische oplossingen voor de meest complexe C++- naar Java-issues:

1. Meervoudige Erfenis (Multiple Inheritance):

   • DAO's: Waar een klasse erfde van een DAO en een andere klasse, werd de "is-a" relatie omgezet in een "has-a" relatie. De DAO werd een veld (member) in de klasse, en toegangsmethoden werden aangepast.
   • Chain of Command: Voor klassen die erfden van een Chain-klasse, werd het patroon herschreven. In plaats van directe pointer-traversing, wordt een ChainManager gebruikt die de controle doorgeeft aan links in de keten via een runNext() methode.
   • Overige gevallen: Klassieken die niet in bovenstaande categorieën pasten, werden gefactord naar abstracte klassen zonder state (die fungeren als interfaces) of handmatig aangepast.

2. Stream I/O:

   • C++ std::cout en std::cin operaties werden gemapt naar StringBuilder-concatenaties.
   • De transpiler detecteert of een std::endl wordt gebruikt om te bepalen of System.out.println() of System.out.print() moet worden gegenereerd.

3. Enums en Integers:

   • Omdat C++-enums vaak als integers worden behandeld (en vice versa), maar Java dit niet toestaat, werd een wrapper-structuur ontwikkeld.
   • Een C++-enum wordt omgezet in een Java-klasse met een constructor die een int accepteert en een asNum() methode.
   • Een statische forNum(int) methode zorgt voor de conversie van een integer naar het enum-object, inclusief validatie en het werpen van een uitzondering bij ongeldige waarden.

4. Constructors en Destructors (Resource Management):

   • C++-destructors worden niet automatisch uitgevoerd in Java. Om het RAII-patroon (Resource Acquisition Is Initialization) te behouden, werd het Try-with-resources patroon (Java 7+) toegepast.
   • Klassen die resources (zoals database cursors) beheerden, werden geannoteerd zodat de transpiler deze in een try (...) blok plaatste, waarbij de close() methode automatisch wordt aangeroepen.

5. Uitzonderingen (Exceptions):

   • De originele C++-code gebruikte zelden exceptions (vaak error codes). In Java is dit anders. De auteurs besloten om de strategie voor exception-handling voorlopig open te laten, maar erkenden dat dit een kritieke architecturale beslissing is voor de stabiliteit van de applicatie op de server.

Resultaten

• Succesvolle Conversie: De tool slaagde erin om de overgrote meerderheid van de 800.000 regels code automatisch te converteren.
• Foutreductie: Er was een duidelijke daling in het aantal compilatiefouten in de gegenereerde Java-code tijdens de ontwikkeling. Een significante daling werd waargenomen na de implementatie van het Java-type-systeem in de transpiler, wat type-mismatchen en enum-fouten oploste.
• Aanloop naar Productie: Aan het einde van het project bleven ongeveer 60 klassen over die handmatige correcties vereisten. De resulterende Java-code kon worden gecompileerd en uitgevoerd op WildFly, met succes voor basisoperaties.
• Efficiëntie: De automatische aanpak maakte het mogelijk om te blijven ontwikkelen in C++ terwijl de Java-versie continu werd bijgewerkt, wat handmatig onmogelijk was geweest.

Betekenis

Dit paper is significant omdat het een praktische, bewezen case-study biedt van het migreren van een groot, complex C++-systeem naar Java EE, waarbij niet alleen de taal, maar ook de architectuur wordt veranderd. Het demonstreert dat:

1. Geautomatiseerde conversie haalbaar is voor grote codebases, mits gebaseerd op robuuste parsers zoals Clang.
2. Specifieke "C++-idiomen" (zoals meervoudige erfenis en RAII) systematisch kunnen worden gemapt naar Java-constructies zonder de leesbaarheid van de code volledig te verliezen.
3. Een hybride aanpak (automatische transformatie + gecontroleerde handmatige correctie) de meest kosteneffectieve strategie is voor dergelijke migraties.

De studie biedt waardevolle inzichten voor andere organisaties die worstelen met legacy-systemen en de noodzaak hebben om te migreren naar moderne, platformonafhankelijke technologieën.