💻 computer science

MigrationBench: Repository-Level Code Migration Benchmark from Java 8

Questo articolo introduce MigrationBench, un benchmark completo a livello di repository e un framework di valutazione per la migrazione del codice Java 8 verso versioni LTS moderne (17 e 21), dimostrando che un framework di LLM agentic può raggiungere tassi di successo elevati su questo compito impegnativo.

Autori originali: Linbo Liu, Xinle Liu, Qiang Zhou, Lin Chen, Yihan Liu, Hoan Nguyen, Behrooz Omidvar-Tehrani, Xi Shen, Jun Huan, Omer Tripp, Anoop Deoras

Pubblicato 2026-05-29

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Linbo Liu, Xinle Liu, Qiang Zhou, Lin Chen, Yihan Liu, Hoan Nguyen, Behrooz Omidvar-Tehrani, Xi Shen, Jun Huan, Omer Tripp, Anoop Deoras

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di avere una biblioteca enorme e antica, piena di libri scritti in uno stile specifico e leggermente obsoleto di inglese (chiamiamolo "Inglese 8"). La biblioteca è gigantesca, contiene migliaia di libri e ognuno di essi è attualmente in perfette condizioni.

Ora, immagina che il consiglio di amministrazione della biblioteca decida di aggiornare l'intero edificio a uno standard moderno e nuovo ("Inglese 17"). Non si tratta solo di cambiare il carattere tipografico; riguarda l'aggiornamento delle regole grammaticali, del vocabolario e del modo in cui i libri sono organizzati, affinché funzionino con i sistemi di sicurezza e gli ascensori del nuovo edificio.

MigrationBench è una sfida gigantesca creata dai ricercatori di AWS AI per testare quanto bene l'Intelligenza Artificiale (in particolare i Modelli Linguistici su larga scala o LLM) possa gestire questo massiccio progetto di ristrutturazione.

Ecco la spiegazione del loro lavoro utilizzando analogie semplici:

1. Il Problema: Spostare un'Intera Città, Non Solo una Casa

La maggior parte dei precedenti test sull'IA era come chiedere a un robot di riparare un singolo rubinetto che perde o scrivere un singolo paragrafo. Ma il software del mondo reale non è un singolo file; è un'intera città di edifici interconnessi (un "repository").

La Sfida: Passare dall'"Inglese 8" all'"Inglese 17" richiede di modificare migliaia di file contemporaneamente. Se cambi un segnale stradale, potresti rompere i semafori a tre isolati di distanza.
Il Divario: Fino ad ora, non esisteva un "esame" standardizzato per vedere se l'IA poteva gestire la ristrutturazione di un'intera città di codice senza far crashare l'intero sistema.

2. La Soluzione: Il Dataset "MigrationBench"

I ricercatori hanno costruito una vasta suite di test chiamata MigrationBench.

Il Dataset Completo: Hanno raccolto 5.102 progetti Java reali e open source da internet (come GitHub). Li hanno filtrati per garantire che fossero di alta qualità, avessero licenze appropriate e funzionassero attualmente in modo perfetto.
Il Sottogruppo "Selezionato": Testare tutti i 5.000+ progetti richiede un'eternità. Quindi, ne hanno selezionati a mano 300 dei progetti più complessi, intricati e interessanti. Pensate a questo come alla versione "Esame Finale" del dataset, progettata per mettere davvero sotto stress l'IA.

3. Le Regole del Gioco (Valutazione)

Come si sa se la ristrutturazione è stata un successo? I ricercatori hanno stabilito due livelli di difficoltà:

Livello 1: Migrazione Minima (Il Test "Funziona")
- Obiettivo: L'IA deve solo assicurarsi che il codice venga compilato (costruito) e che tutti i test esistenti passino nella nuova versione.
- Analogia: L'edificio è sicuro, le luci si accendono e gli ascensori funzionano. I libri sono leggibili.
- Tasso di Successo: Con la loro migliore configurazione di IA, hanno ottenuto un tasso di successo del 71,67% qui.
Livello 2: Migrazione Massima (Il Test "Modernizzazione")
- Obiettivo: L'IA non deve solo far funzionare il codice, ma anche aggiornare ogni singolo strumento e libreria all'interno del codice alle loro versioni assolutamente più recenti e sicure.
- Analogia: Non solo l'edificio è sicuro, ma l'IA ha anche sostituito tutte le vecchie tubature con nuove tubature in rame, aggiornato le telecamere di sicurezza a 4K e installato le ultime funzionalità per la casa intelligente. Questo è molto più difficile perché i nuovi strumenti spesso hanno regole diverse.
- Tasso di Successo: Questo è molto più arduo. La migliore configurazione di IA ha ottenuto un tasso di successo del 53,33%.

4. I Lavoratori: Agenti IA

I ricercatori non hanno chiesto semplicemente all'IA di "scrivere codice". Hanno costruito Agenti IA – lavoratori digitali equipaggiati con strumenti.

Il Lavoratore Base: Un'IA semplice che guarda il codice e cerca di correggere gli errori. Ha faticato con l'aggiornamento "Massimo".
Il Lavoratore Intelligente (Prompt Engineering): Hanno fornito al lavoratore base un insieme migliore di istruzioni, dicendogli specificamente di aggiornare tutto. Questo ha aiutato molto.
Il Lavoratore Ricercatore (RAG): Hanno fornito al lavoratore un "elenco telefonico" (una base di conoscenza) delle versioni software più recenti in modo che non dovesse indovinare. Questo ha ulteriormente migliorato i risultati.
Il Team Ibrido (Il Vincitore): Questo è stato l'approccio più astuto. Hanno utilizzato un programma per computer per sostituire automaticamente i vecchi strumenti con quelli nuovi (un passo rapido e robotico) e poi hanno lasciato che l'Agente IA intervenisse per sistemare le parti disordinate dove i nuovi strumenti non si adattavano perfettamente.
- Risultato: Questo team ha ottenuto risultati pari al lavoratore IA più costoso ma ha utilizzato l'11% in meno di potenza di calcolo.

5. I Risultati

Il documento mostra che, sebbene l'IA stia diventando molto brava a risolvere piccoli problemi di codice, ristrutturare un'intera "città" di software da una vecchia versione a una nuova è ancora una sfida enorme.

L'approccio Ibrido (combinando strumenti automatizzati con l'IA) si è rivelato il modo più efficiente per farlo.
Il dataset e il codice per questi agenti IA sono ora pubblici, in modo che altri ricercatori possano provare a costruire team di ristrutturazione ancora migliori.

In sintesi: MigrationBench è una nuova palestra rigorosa per l'IA per esercitarsi a spostare intere librerie di software dalle vecchie versioni a quelle nuove. Dimostra che, sebbene l'IA sia capace, le "ristrutturazioni" più complesse richiedono ancora una miscela intelligente di strumenti automatizzati e ragionamento simile a quello umano per svolgere il lavoro correttamente.

Riepilogo Tecnico: MigrationBench

Enunciato del Problema

Sebbene i Modelli Linguistici su Larga Scala (LLM) abbiano dimostrato un successo significativo nella generazione di codice e nella risoluzione di problemi isolati, le loro capacità nella migrazione di codice a livello di repository rimangono sottostimate. A differenza di compiti focalizzati su singole funzioni o file, la migrazione del codice richiede un approccio olistico per navigare problemi interconnessi in un'intera base di codice, in particolare durante l'aggiornamento di sistemi legacy. Nello specifico, manca un dataset di benchmark su larga scala e di alta qualità progettato per valutare la migrazione di repository Java 8 verso versioni moderne di Supporto a Lungo Termine (LTS) (Java 17 e 21). I benchmark esistenti si concentrano spesso sulla generazione di codice, sulla traduzione tra linguaggi o su compiti di manutenzione su piccola scala, non riuscendo a catturare la complessità e la scala di scenari di migrazione reali che coinvolgono migliaia di righe di codice e alberi di dipendenze complessi.

Metodologia

1. Curazione del Dataset (MigrationBench)

Gli autori introducono MigrationBench, il primo benchmark su larga scala per la migrazione di repository Java. Il processo di curazione ha coinvolto una pipeline di filtraggio rigorosa e multi-step applicata ai repository GitHub:

Filtraggio Iniziale: I repository sono stati filtrati in base alla licenza (MIT/Apache 2.0), alla qualità (minimo 3 stelle) e allo strumento di build (Maven).
Verifica della Compatibilità: Il team ha identificato un "commit di base" ( $H_b$ ) per ogni repository in cui il codice viene compilato con successo e supera i test sotto Java 8. Ciò ha comportato la verifica delle configurazioni pom.xml, assicurando che non vi fossero versioni Java 8 hardcoded incompatibili con l'obiettivo e validando che le versioni principali delle classi compilate fossero 52 (Java 8).
Deduplicazione: I repository sono stati deduplicati in base a corrispondenze esatte degli hash dei file e del contenuto.
Requisito sui Test: I repository sono stati suddivisi in un dataset Full (5.102 repository con test unitari) e un sottoinsieme UTG (4.814 repository senza test). Il dataset Full funge da benchmark principale per la valutazione della migrazione.
Sottoinsieme Selezionato: È stato curato un sottoinsieme rappresentativo di 300 repository (selected) dal dataset Full. Questo sottoinsieme enfatizza repository più grandi e multi-modulo per riflettere meglio la diversità e l'intricatezza delle sfide di migrazione reali.

2. Framework di Valutazione

A causa dell'assenza di repository target di verità fondamentale (ground-truth), gli autori propongono un framework di valutazione automatizzato basato sull'Equivalenza Funzionale Approssimata (FE):

Migrazione Minima: Definita da quattro criteri:
1. Successo della Build: mvn clean verify ha esito positivo sotto Java 17.
2. Validazione della Versione: Le classi compilate hanno una versione principale di 61 (Java 17).
3. Invarianza dei Metodi di Test: I metodi di test (annotati con @Test) non sono rinominati, disabilitati o rimossi (verificato tramite parsing AST).
4. Invarianza del Numero di Test: Il numero di casi di test non diminuisce.
Migrazione Massima: Si basa sulla migrazione minima aggiungendo un quinto criterio:
1. Modernizzazione delle Dipendenze: Tutte le dipendenze sono aggiornate alle loro ultime versioni stabili principali disponibili su Maven Central (a novembre 2024).

3. Framework Agentic

Il documento valuta diversi approcci basati su agenti utilizzando il framework Strands agent e Claude-4.5-Sonnet:

Baseline (Strands Agent): Dotato di strumenti shell e di modifica per migrare il codice e garantire che mvn clean verify abbia esito positivo.
Agente di Prompt Engineering (PE): Potenziato con prompt di sistema che istruiscono esplicitamente l'agente a aggiornare tutte le dipendenze alle loro ultime versioni principali.
Agente RAG: Incorpora un approccio di Generazione Aumentata dal Recupero (Retrieval-Augmented Generation) in cui l'agente interroga una base di conoscenza esterna sulle dipendenze per identificare le versioni corrette più recenti.
Approccio Ibrido: Combina l'analisi statica del codice (aggiornamento deterministico delle dipendenze) con l'agente LLM. Lo strumento statico gestisce gli aggiornamenti di versione, mentre l'agente risolve i fallimenti di build risultanti e i problemi di compatibilità.

Contributi Chiave

Dataset MigrationBench: L'introduzione del primo benchmark su larga scala per la migrazione di codice a livello di repository, comprendente 5.102 repository (Full) e un sottoinsieme curato di 300 repository (Selected).
Framework di Valutazione: Un framework completo e automatizzato per valutare il successo della migrazione attraverso criteri minimi e massimi, affrontando la mancanza di verità fondamentale nei compiti di migrazione.
Soluzioni Agentic: La proposta e la valutazione di un flusso di lavoro agentic per la migrazione del codice, inclusa una nuova Approccio Ibrido che combina analisi statica con ragionamento LLM per migliorare l'efficienza.
Risorse Aperte: Il rilascio del dataset, del codice sorgente di valutazione e delle traiettorie dettagliate degli agenti (inclusi decisioni intermedie e modalità di fallimento) per supportare la riproducibilità e la ricerca futura.

Risultati Sperimentali

Gli esperimenti sono stati condotti sul sottoinsieme selected (300 repository) utilizzando il framework Strands agent con Claude-4.5-Sonnet.

Migrazione Minima: L'agente Strands baseline ha raggiunto un tasso di successo del 71,67% (pass@1) per la migrazione minima.
Migrazione Massima:
- L'agente baseline ha raggiunto solo un 15,33% di successo.
- L'aggiunta del Prompt Engineering (PE) ha aumentato l'efficacia al 45,67%.
- L'integrazione di RAG ha migliorato ulteriormente l'efficacia al 53,33%.
- L'Approccio Ibrido ha eguagliato l'efficacia dell'agente RAG del 53,33% riducendo al contempo il numero medio di chiamate LLM per repository (52,55 contro 59,22), dimostrando un compromesso favorevole tra costo ed efficienza.
Confronto tra Modelli: Applicando l'Approccio Ibrido ad altri modelli (DeepSeek-V3.1, Qwen3-Coder-480B, GLM-5), Claude-4.5-Sonnet è rimasto il più efficace, sebbene altri modelli abbiano mostrato diversi gradi di successo (ad esempio, GLM-5 ha raggiunto il 45,33%).
Compilazione vs. Verifica: Disabilitando i test unitari (affidandosi solo a mvn clean compile) l'efficacia della migrazione minima è aumentata dal 71,67% al 97,67%, evidenziando il ruolo critico delle suite di test nella validazione dell'equivalenza funzionale.

Significato e Affermazioni

Il documento posiziona MigrationBench come una risorsa fondamentale per avanzare la ricerca nell'ingegneria del software e nelle capacità degli LLM. Gli autori affermano che:

Divario di Complessità: I compiti di migrazione presentano un livello di difficoltà significativamente superiore rispetto alla generazione di codice o alla risoluzione di problemi isolati, richiedendo una comprensione olistica del repository.
Fattibilità: Gli LLM, in particolare quando guidati da flussi di lavoro agentic e conoscenze esterne (RAG) o analisi statica ibrida, possono affrontare efficacemente la migrazione a livello di repository da Java 8 a Java 17.
Standardizzazione: Il framework di valutazione proposto fornisce un metodo rigoroso e standardizzato per valutare il successo della migrazione, andando oltre i semplici controlli di compilazione per includere la modernizzazione delle dipendenze e la preservazione dei test.
Direzione Futura: Il rilascio delle traiettorie degli agenti e del sottoinsieme UTG apre nuove vie per studiare i limiti degli agenti, le modalità di fallimento e la generazione di test unitari per codice legacy.

Gli autori riconoscono le limitazioni, inclusa la dipendenza dalla copertura dei test esistente (che potrebbe non garantire la piena equivalenza funzionale per il codice non testato) e potenziali problemi di riproducibilità dovuti al throttling di Maven Central durante la raccolta dati su larga scala. Tuttavia, sostengono che MigrationBench offra una base solida per una valutazione sistematica e riproducibile dei metodi di migrazione del codice.