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

Questo rapporto descrive l'esperienza e le tecniche impiegate per convertire un monolite C++ da 800.000 righe in un'applicazione Java EE eseguita su WildFly, affrontando sfide architetturali e linguistiche specifiche attraverso lo sviluppo di un tool basato su clang per la rigenerazione continua del codice.

L'essenziale

Immagina di avere un gigantesco edificio storico costruito in pietra e mattoni (il codice C++ di 800.000 righe). Questo edificio è un "monolite": tutto è unito, funzionante, ma molto vecchio e difficile da espandere. Ora, la società che lo possiede vuole trasformarlo in un grattacielo moderno in vetro e acciaio (il codice Java), che deve seguire regole di sicurezza molto più rigide (l'architettura Java EE) e deve essere abitato da nuovi inquilini (sviluppatori Java) che non parlano la lingua degli architetti originali.

Il problema? L'edificio è ancora in uso mentre lo si sta ricostruendo. Non si può fermare tutto per un mese e ricominciare da zero.

Ecco la storia di come un team ha affrontato questa sfida, spiegata come se fosse un'avventura di ristrutturazione.

1. Il Grande Problema: Tradurre senza "Copiare e Incollare"

Se provassi a tradurre manualmente ogni singola riga di questo codice, ci vorrebbero anni e commetteresti errori ovunque. È come se dovessi riscrivere a mano un'enciclopedia intera mentre qualcuno continua a scrivere nuove pagine.
La soluzione? Hanno costruito un traduttore robotico (uno strumento chiamato "transpiler" basato su clang). Questo robot legge il vecchio codice C++ e scrive automaticamente il nuovo codice Java. Ma non è un traduttore magico: deve essere istruito su come risolvere i "drammi" linguistici tra le due lingue.

2. I "Drammi" Linguistici (Le Sfide)

Il C++ e il Java sono come due lingue sorelle che hanno preso strade diverse. Ecco i tre ostacoli principali che il robot ha dovuto superare:

A. L'Inheritance Multipla (Il "Figlio di Due Padri")

In C++, una classe (un tipo di oggetto) può ereditare caratteristiche da due o più "padri". È come se un bambino avesse due padri biologici e prendesse in prestito i superpoteri da entrambi.
In Java, invece, un bambino può avere un solo padre biologico (eredità singola), ma può avere molti "padri spirituali" (interfacce) che gli insegnano solo cosa fare, non come farlo (non possono avere dati interni).

• La soluzione: Il robot ha dovuto fare un'operazione chirurgica. Se un "figlio" aveva un padre che era un "DAO" (un gestore di database), il robot ha trasformato il rapporto da "sono figlio di" a "ho un padre che vive con me". In pratica, invece di ereditare il database, l'oggetto ora lo contiene dentro di sé. Se il secondo padre era un "Chain of Command" (una catena di comando), il robot ha cambiato il modo in cui passano il testimone, trasformando una catena rigida in un gioco di "passa il testimone" più fluido.

B. Gli Enum (I Colori vs. I Numeri)

In C++, un "enum" (un elenco di opzioni, come i colori: Rosso, Nero, Bianco) è in realtà solo un numero nascosto. Puoi dire al computer: "Prendi il colore Rosso (che è 0) e assegnagli il numero 42". Il C++ lo accetta, anche se è assurdo.
In Java, gli enum sono oggetti veri e propri. Non puoi assegnare un numero a un colore a caso, o il computer ti dirà "No, non funziona".

• La soluzione: Il robot ha costruito un "traduttore di sicurezza". Quando vede un numero che dovrebbe essere un colore, crea una piccola scatola speciale (un oggetto) che contiene quel numero e controlla se è un colore valido. Se provi a mettere il numero 42 in una scatola "Rosso", il robot lancia un allarme invece di far esplodere il sistema.

C. I Distruttori (Il "Pulisci dopo di te")

In C++, quando un oggetto finisce il suo lavoro, ha un "distruttore" che si assicura di pulire tutto (chiude i file, libera la memoria). È come un maggiordomo che, quando il padrone esce, spegne le luci e chiude la porta.
In Java, non c'è un maggiordomo automatico che sa esattamente quando spegnere le luci. C'è un "spazzino" (Garbage Collector) che passa di tanto in tanto a pulire, ma non è preciso.

• La soluzione: Hanno usato una nuova regola Java chiamata "Try-with-resources". Immagina di mettere gli oggetti importanti in una "scatola magica" all'inizio di un compito. Appena il compito finisce (anche se c'è un errore), la scatola si chiude automaticamente e pulisce tutto. Il robot ha identificato quali oggetti avevano bisogno di questa scatola e li ha inseriti automaticamente.

3. Il Robot e il Controllo Umano

Il robot non è perfetto. Ha commesso errori su circa 10 classi su 3.000.
Invece di cercare di rendere il robot perfetto (cosa che avrebbe richiesto anni), hanno usato un approccio intelligente:

1. Il robot fa il lavoro sporco per il 99%.
2. Se il robot produce un codice che sembra "sbagliato" (ma che in realtà è solo diverso dal previsto), il sistema lo confronta con un modello corretto.
3. Se corrisponde, lo sovrascrive con la versione umana corretta.
4. Ogni volta che qualcuno modifica il vecchio codice C++, il robot ripete il processo, avvisando gli umani se le modifiche toccano quelle 10 classi problematiche.

4. Il Risultato: Un Successo

Alla fine, il team è riuscito a:

• Convertire 800.000 righe di codice.
• Ridurre gli errori di compilazione da migliaia a solo 60 (corretti manualmente alla fine).
• Far funzionare il nuovo sistema Java su un server moderno (WildFly).

In sintesi:
Hanno preso un vecchio edificio di pietra, lo hanno smontato mattoncino per mattoncino usando un robot, e lo hanno rimontato come un grattacielo moderno, assicurandosi che ogni finestra e ogni porta funzionasse secondo le nuove regole di sicurezza. Non è stato perfetto (hanno dovuto aggiustare a mano alcune finestre), ma il risultato è un edificio solido, sicuro e pronto per il futuro, tutto mentre la gente continuava a viverci dentro.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del documento "Experience on Automatically Converting a C++ Monolith to Java EE", presentato in italiano.

Titolo: Esperienza nella Conversione Automatica di un Monolite C++ in Java EE

1. Il Problema

L'articolo descrive la sfida di migrare un'applicazione server di grandi dimensioni (un "monolite") scritta in C++ (circa 800.000 righe di codice) verso Java 8, parallelamente a un cambiamento architetturale verso un'applicazione basata su un server applicativo (WildFly).
Le principali difficoltà identificate includono:

• Continuità dello sviluppo: La conversione doveva avvenire mentre lo sviluppo del codice C++ originale continuava, rendendo impossibile un approccio manuale o una riscrittura da zero.
• Differenze linguistiche: C++ e Java presentano differenze fondamentali, tra cui:
  • Ereditarietà multipla (supportata in C++, non in Java).
  • Gestione degli enum (in C++ sono spesso trattati come interi, in Java sono oggetti tipizzati).
  • Distruttori e gestione delle risorse (RAII in C++ vs Garbage Collection in Java).
  • I/O basato su stream (std::ostream/std::istream).
  • Costruttori con effetti collaterali.
• Obiettivo aziendale: Unificare i sistemi logistici di diversi prodotti aziendali, passando da C++98 a Java per facilitare l'assunzione di sviluppatori, mantenendo la funzionalità del sistema durante la transizione.

2. Metodologia

Gli autori hanno sviluppato un transpiler (compilatore trasformativo) basato su LLVM/Clang-tool per automatizzare la conversione. La metodologia si articola in diverse fasi e componenti:

• Analisi e Parsing: L'uso di clang-tool permette di analizzare il codice C++ esistente, costruendo un Abstract Syntax Tree (AST) robusto. Il transpiler visita l'AST per identificare costrutti problematici.
• Architettura del Transpiler:
  • Visitor Pattern: Utilizzo di visitor (es. ConstDeclVisitor, ConstStmtVisitor) per attraversare l'AST.
  • Rewriter/Template Engine: Un motore di template che mappa i costrutti C++ al loro equivalente Java. Utilizza un sistema di "placeholder" (es. {{type}}, {{expr}}) per generare codice Java dinamico.
  • Mappatura delle Funzioni: Tabelle di mappatura per convertire funzioni libere C++ in metodi statici Java e per gestire le espressioni dei membri delle classi standard (es. std::string, std::map).
  • Gestione dei Tipi: Implementazione di un sistema di tipi ibrido che risolve i tipi canonici C++ (es. unsigned long long) e li mappa ai tipi Java corrispondenti per evitare cast impliciti errati e gestire correttamente gli enum.
• Strategia di Conversione Iterativa:
  • Il processo è automatizzato ma prevede un controllo manuale ("checked replace") per le classi critiche.
  • Il sistema è integrato nel processo di build: ogni commit nel repository C++ triggera una nuova generazione del codice Java, permettendo di rilevare immediatamente le regressioni o le modifiche alle classi problematiche.

3. Contributi Chiave e Soluzioni Tecniche

Il paper dettaglia soluzioni specifiche per le sfide principali:

• Ereditarietà Multipla:
  • Caso DAO (Data Access Object): Trasformazione della relazione "è un" (ereditarietà) in "ha un" (composizione). La classe DAO diventa un membro della classe derivata.
  • Caso Chain of Command: Ristrutturazione del pattern di catena di comando. Invece di puntatori diretti, viene introdotto un "Chain Manager" che gestisce il flusso di controllo tra i link, simulando la traversata della catena tramite callback (runNext).
  • Casi Generali: Le classi con ereditarietà multipla non standard sono state analizzate per vedere se potevano essere convertite in interfacce Java. I casi residui (meno di 5) sono stati gestiti manualmente con guardie di build.
• Gestione degli Enum:
  • Poiché Java non permette l'assegnazione arbitraria di interi agli enum, gli enum C++ sono stati convertiti in classi Java con un costruttore privato e metodi statici (forNum) per la conversione da/verso interi. Questo mantiene la sicurezza di tipo di Java preservando la semantica C++.
• Gestione delle Risorse (Costruttori/Distruttori):
  • Per gestire i distruttori C++ (RAII) che rilasciano risorse (es. cursori di database), è stato adottato il pattern Try-with-resources di Java (introdotto in Java 7).
  • Le classi C++ con distruttori non vuoti sono state annotate manualmente per generare blocchi try-with-resources in Java, garantendo la chiusura delle risorse anche in caso di eccezioni.
• I/O Stream:
  • Gli stream C++ (std::cout, std::cin) sono stati mappati a StringBuilder per la concatenazione efficiente, con output finale su System.out.println o System.out.print a seconda della presenza di std::endl.
• Gestione delle Eccezioni:
  • Il codice C++ originale usava raramente le eccezioni (preferendo codici di errore). In Java, dove le eccezioni sono più comuni, la strategia di gestione è rimasta in fase di discussione (ignorare, gestire a livello di catena o a ogni link), con una preferenza per la gestione locale (try-catch), sebbene costosa.

4. Risultati

• Riduzione degli Errori: Il grafico riportato nel paper (Fig. 12) mostra una drastica riduzione degli errori di compilazione Java nel tempo. Un calo significativo è stato osservato con l'introduzione del sistema di tipi Java, che ha corretto errori di casting e conversione enum/int.
• Stato Finale: Al momento della conclusione del progetto (da parte degli autori), rimanevano circa 60 classi che richiedevano correzioni manuali su un totale di 3.000 classi.
• Funzionalità: Il codice Java generato è stato compilato con successo ed eseguito sul server WildFly, permettendo operazioni semplici e dimostrando la fattibilità dell'approccio.
• Efficienza: L'approccio basato su tool ha permesso di mantenere il codice C++ aggiornato e di generare continuamente una versione Java coerente, riducendo il debito tecnico rispetto a una riscrittura manuale.

5. Significato e Impatto

Questo studio di caso è significativo per diversi motivi:

1. Fattibilità della Migrazione Automatica: Dimostra che è possibile migrare un monolite C++ complesso e in evoluzione verso Java EE in modo automatizzato, superando ostacoli architetturali e linguistici apparentemente insormontabili.
2. Approccio Ibrido: Sottolinea l'importanza di un approccio ibrido: automazione per la massa del codice e intervento manuale mirato per le eccezioni, gestito attraverso un processo di build continuo.
3. Adattamento Architetturale: Mostra come la conversione linguistica possa essere usata come leva per modernizzare l'architettura (passaggio da monolite a server applicativo) senza dover riscrivere tutto da zero.
4. Riuso del Codice: L'uso di template e mappature permette di preservare la logica di business originale mentre si adatta al nuovo paradigma, riducendo il rischio di introduzione di nuovi bug durante la migrazione.

In sintesi, il paper offre una roadmap pratica e tecnica per aziende che affrontano la migrazione di sistemi legacy critici, evidenziando come l'uso di strumenti di analisi del codice (come Clang) combinato con strategie di trasformazione intelligenti possa portare al successo anche in scenari di alta complessità.