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

Ce rapport présente l'expérience et les techniques utilisées pour convertir une base de code C++ monolithique de 800 000 lignes en une application Java EE fonctionnant sur WildFly, en abordant des défis spécifiques comme l'héritage multiple et en développant un outil basé sur clang pour régénérer continuellement le code Java.

L'essentiel

Voici une explication simple et imagée de ce rapport technique, traduite en français pour un public général.

🚚 Le Grand Déménagement : De C++ à Java

Imaginez qu'une entreprise de logistique possède une énorme usine (son logiciel) construite entièrement en briques rouges (le langage C++). Cette usine est énorme : elle contient 800 000 briques ! Elle fonctionne très bien, mais l'entreprise veut la reconstruire en briques bleues (le langage Java) pour deux raisons :

1. Il est plus facile de trouver des maçons spécialisés dans les briques bleues.
2. Ils veulent changer la structure de l'usine pour qu'elle s'intègre mieux dans un nouveau quartier (un serveur d'applications moderne).

Le problème ? L'usine continue de fonctionner et de produire des marchandises pendant qu'on essaie de la reconstruire. Si on essaie de déplacer chaque brique à la main, cela prendrait des années et on ferait beaucoup d'erreurs.

🤖 La Solution : Le Robot Traducteur

Au lieu de faire appel à une armée de maçons, les auteurs ont construit un robot super-intelligent (un outil appelé "transpileur") basé sur une technologie de pointe (Clang/LLVM). Ce robot lit les plans en briques rouges et dessine automatiquement les plans en briques bleues.

Mais attention, ce n'est pas une simple traduction mot à mot comme un dictionnaire. C'est comme si le robot devait transformer un bateau en voiles (C++) en un sous-marin (Java) tout en gardant la même capacité à transporter des marchandises.

🧩 Les 4 Défis Majeurs (et comment le robot les a résolus)

Voici les quatre obstacles principaux que le robot a dû surmonter, expliqués avec des analogies :

1. Le Problème des "Super-Héros" (L'héritage multiple)

• Le problème : En C++, une classe (un objet) peut avoir deux parents (hériter de deux autres classes). Imaginez un enfant qui hérite des yeux de son père et des cheveux de sa mère. En Java, un enfant n'a qu'un seul père biologique.
• La solution du robot :
  • Si l'un des parents est un "gestionnaire de base de données" (DAO), le robot dit : "D'accord, tu n'as plus ce parent, mais tu vas héberger ce parent dans ta maison." (On passe de "être un" à "avoir un").
  • Si l'autre parent est une "chaîne de commandement", le robot réorganise la hiérarchie pour que le sous-marin suive un nouveau protocole de communication.
  • Pour les cas trop complexes (comme un enfant avec 5 parents), le robot a dit : "Je ne peux pas faire ça tout seul, un humain doit intervenir."

2. Le Problème des "Mots-Clés" (Les Enums)

• Le problème : En C++, un "Enum" (une liste de choix comme Rouge, Vert, Bleu) est en réalité juste un nombre caché. On peut lui donner n'importe quel nombre, même 42 pour "Vert", et le code acceptera. En Java, c'est strict : si c'est "Vert", ça doit être "Vert".
• La solution du robot : Le robot a transformé chaque liste de choix en une petite boîte sécurisée. Au lieu de juste un nombre, il crée un objet spécial qui vérifie : "Est-ce que ce nombre correspond bien à une couleur autorisée ?". Si non, il lance une alerte au lieu de laisser passer une erreur silencieuse.

3. Le Problème du "Nettoyage" (Constructeurs et Destructeurs)

• Le problème : En C++, quand un objet finit sa vie, il a un "destructor" (un agent de nettoyage) qui ferme automatiquement les portes et éteint les lumières (libère la mémoire). En Java, il n'y a pas d'agent de nettoyage automatique qui vient à la fin de la vie d'un objet.
• La solution du robot : Le robot a appris à utiliser une nouvelle règle de sécurité appelée "Try with Resources". C'est comme mettre un objet dans une boîte à chaussures (le bloc try). Dès qu'on sort de la boîte, peu importe si on est parti volontairement ou qu'on a trébuché, le robot s'assure que tout est rangé et propre.

4. Le Problème des "Messages" (Les flux d'entrée/sortie)

• Le problème : Le logiciel C++ parlait en utilisant des "flux" (comme un tuyau d'arrosage qui envoie des données). Java parle différemment, il préfère assembler des phrases dans un bloc-notes.
• La solution du robot : Le robot a appris à transformer le tuyau d'arrosage en un assemblage de blocs de construction (StringBuilder). Au lieu de jeter les mots un par un, il les colle les uns aux autres de manière efficace avant de les envoyer.

🏁 Le Résultat : Une Usine Réussie

Au début, le robot a produit beaucoup de "briques bleues" mal assemblées (des erreurs de compilation). Mais à mesure que le robot apprenait de ses erreurs et que les humains ajustaient ses règles, le nombre d'erreurs a chuté drastiquement (comme le montre le graphique de la fin).

À la fin du projet, il ne restait que quelques dizaines d'erreurs mineures. Les humains ont pu les corriger à la main en quelques minutes. Le résultat ?

• Le logiciel fonctionne parfaitement sur le nouveau serveur.
• Il est plus facile à maintenir.
• L'entreprise a réussi à migrer son système sans arrêter la production.

En résumé : C'est l'histoire d'une équipe qui a construit un robot pour transformer un vieux château en pierre en un gratte-ciel moderne, tout en continuant à y vivre, en utilisant des règles de sécurité strictes pour éviter que tout ne s'effondre.

Résumé technique

Voici un résumé technique détaillé de l'article « Experience on Automatically Converting a C++ Monolith to Java EE », rédigé en français.

1. Problématique et Contexte

L'article décrit le défi majeur consistant à migrer une base de code C++ existante de 800 000 lignes (réparties sur environ 2 500 fichiers et 3 000 classes) vers Java 8. Ce projet ne se limitait pas à une simple conversion de syntaxe ; il impliquait une refonte architecturale profonde : passer d'une application monolithique autonome (serveur unique) à une architecture basée sur un serveur d'applications Java (WildFly).

Les principaux obstacles identifiés étaient :

• La complexité linguistique : Les différences fondamentales entre C++ et Java, notamment l'absence de destructeurs, de l'héritage multiple, et la gestion stricte des énumérations (enums) en Java.
• La continuité du développement : La base de code C++ devait continuer à évoluer (ajout de fonctionnalités, corrections de bugs) pendant la conversion, rendant une approche manuelle impossible et trop sujette aux erreurs.
• L'architecture cible : L'adoption d'un serveur d'applications Java imposait des contraintes supplémentaires (gestion des threads, injection de dépendances, cycle de vie des objets) qui n'existaient pas dans le monolithe C++ original.
• Les idiomes spécifiques : Utilisation intensive de patterns comme RAII (Resource Acquisition Is Initialization) via des destructeurs, des héritages multiples complexes (DAO + Chaîne de commandement), et des conversions implicites entre entiers et enums.

2. Méthodologie et Outils

L'équipe a opté pour une approche automatisée basée sur un transpileur (compilateur de transformation) développé en C++ utilisant le framework LLVM/Clang.

Architecture du Transpileur

Le système repose sur un visiteur AST (Abstract Syntax Tree) central qui parcourt le code C++ et génère du code Java correspondant via un moteur de templates.

• Analyse AST : Utilisation des visiteurs ConstDeclVisitor, ConstStmtVisitor et TypeVisitor de Clang pour analyser les déclarations, les instructions et les types.
• Moteur de Réécriture (Rewriter/Template Engine) :
  • Templates Java : Pour chaque construction C++, un template Java correspondant est défini. Les variables sont injectées dynamiquement.
  • Correspondance des fonctions libres : Un tableau de correspondance mappe les fonctions C-style (ex: atoi) vers des méthodes statiques Java.
  • Réécriture des expressions membres : Une table complexe gère les surcharges d'opérateurs et les méthodes des classes standards (ex: std::string vers java.lang.String), en gérant les différences de signature et de types de retour.
• Gestion des Imports : Contrairement aux #include de C++, le transpileur analyse les types pour déduire automatiquement les packages Java nécessaires et génère les instructions import appropriées.
• Système de Types Hybride : Pour éviter les erreurs de cast, le transpileur maintient un registre de symboles qui suit non seulement le type C++, mais aussi le type Java cible correspondant, permettant de propager les types à travers les expressions (ex: pour éviter des casts inutiles lors d'opérations arithmétiques).

Stratégie de Conversion Continue

Le processus est intégré dans le système de construction (build system). À chaque commit dans le dépôt C++, le transpileur régénère le code Java. Une procédure de « remplacement vérifié » (checked replace) est utilisée : si le code généré correspond à un modèle connu d'erreur, il est remplacé manuellement par une version corrigée. Cela permet de maintenir la cohérence malgré l'évolution continue du code C++.

3. Contributions Techniques Clés (Résolution des Défis)

L'article détaille comment des problèmes spécifiques C++ ont été résolus pour s'adapter à Java :

• Héritage Multiple :

  • Cas DAO : Les classes héritant d'une classe DAO et d'une autre classe ont été restructurées selon le principe « a un » (composition) au lieu de « est un ». La classe DAO est devenue un membre de la classe principale.
  • Cas Chaîne de Commandement (Chain of Command) : La logique de traversal de la chaîne a été réécrite pour utiliser un gestionnaire de chaîne qui appelle itérativement les liens, simulant la pile d'appels Java pour remplacer la récursivité ou les pointeurs C++.
  • Cas génériques : Les classes non conformes ont été refactorisées pour utiliser des interfaces Java, ou converties manuellement avec des garde-fous dans le processus de build.

• Entrées/Sorties (Streams) :

  • Les opérateurs << et >> de std::ostream/std::istream sont convertis en utilisation de StringBuilder pour la concaténation efficace, ou directement en System.out.print/println selon la présence de std::endl.

• Gestion des Enums vs Int :

  • En C++, un enum peut être assigné arbitrairement à un entier. En Java, c'est interdit. Le transpileur convertit chaque enum C++ en une classe Java contenant un constructeur privé, une méthode asNum() pour récupérer la valeur entière, et une méthode statique forNum() pour reconstruire l'objet enum depuis un entier (avec vérification d'erreur). Cela préserve la sécurité de type de Java tout en imitant le comportement C++.

• Constructeurs et Destructeurs (RAII) :

  • Les destructeurs C++ (utilisés pour libérer des ressources comme les curseurs de base de données) n'existent pas en Java. L'équipe a utilisé le pattern Try-with-resources (introduit en Java 7). Les classes C++ utilisant des destructeurs non vides sont annotées pour générer automatiquement des blocs try contenant des objets implémentant Closeable, garantissant la libération des ressources même en cas d'exception.

• Gestion des Exceptions :

  • Le code C++ original utilisait principalement des codes d'erreur plutôt que des exceptions. La stratégie Java a été laissée ouverte (discussion en cours sur l'ajout de blocs try-catch au niveau de la chaîne de commandement ou de chaque lien), car la redémarrage d'une application Java est plus coûteux que celui d'un binaire C++.

4. Résultats

• Réduction des erreurs : La figure 12 du papier montre une diminution drastique du nombre d'erreurs de compilation Java au fil du temps. Une chute significative a été observée après l'introduction du système de types Java dans le transpileur, permettant de corriger les conversions incorrectes entre enums et entiers.
• État final : À la fin du projet, environ 60 erreurs restaient à corriger manuellement sur les 800 000 lignes. Le code Java généré était exécutable et permettait des opérations simples.
• Efficacité : L'approche automatisée a permis de gérer la complexité d'une migration de cette envergure tout en maintenant le développement du code source C++.

5. Signification et Conclusion

Ce projet démontre la faisabilité de la migration de monolithes C++ complexes vers des architectures Java EE modernes grâce à des outils basés sur l'analyse AST (Clang).

Les points clés de la réussite sont :

1. L'automatisation continue : La capacité à régénérer le code à chaque modification du C++ a permis de maintenir la synchronisation entre les deux versions.
2. La gestion intelligente des types : L'intégration d'un système de types Java dans le transpileur a été cruciale pour éviter des erreurs subtiles de conversion (notamment sur les enums).
3. L'adaptation architecturale : Le transpileur n'a pas seulement traduit le code, il a réorganisé la structure (héritage multiple vers composition/interfaces, RAII vers Try-with-resources) pour respecter les bonnes pratiques Java.

Bien que la conversion manuelle de quelques cas complexes (moins de 5 classes) ait été nécessaire, l'approche a permis de transformer une base de code massive en un artefact Java fonctionnel, validant l'usage des outils de transformation de code pour des migrations industrielles à grande échelle.