💻 computer science

ScarfBench: A Benchmark for Cross-Framework Application Migration in Enterprise Java

Questo articolo presenta ScarfBench, un benchmark completo per valutare la capacità degli agenti di codifica AI di eseguire migrazioni tra framework che preservano il comportamento di applicazioni Java aziendali tra Spring, Jakarta EE e Quarkus, rivelando che i modelli all'avanguardia attuali faticano significativamente in questo complesso compito di refactoring.

Autori originali: Advait Pavuluri, Bridget McGinn, Ashita Saxena, George Safta, Srikanth Tamilselvam, Raju Pavuluri, Michele Merler, Baishakhi Ray, Rahul Krishna

Pubblicato 2026-05-12

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Advait Pavuluri, Bridget McGinn, Ashita Saxena, George Safta, Srikanth Tamilselvam, Raju Pavuluri, Michele Merler, Baishakhi Ray, Rahul Krishna

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 casa molto vecchia, ben costruita. È stata abitata per decenni e funziona perfettamente per la famiglia che vive al suo interno. Ma il quartiere sta cambiando. Le vecchie strade (il vecchio framework software) vengono ricoperte di asfalto, e vengono costruite nuove autostrade più veloci (framework moderni). La famiglia vuole spostare i propri mobili e mantenere la propria routine quotidiana esattamente uguale, ma deve trasferirsi in una casa costruita su una fondazione completamente diversa, con impianti idraulici, cablaggi elettrici e maniglie delle porte differenti.

Questo è il problema che SCARFBENCH sta cercando di risolvere.

Il Problema: Spostare una Casa, Non Solo Dipingerla

Nel mondo del software informatico, molte grandi aziende fanno funzionare i propri sistemi su "Java", un linguaggio di programmazione popolare. Questi sistemi sono spesso costruiti su tre specifici "framework" (immagina questi come diversi stili architettonici o progetti): Spring, Jakarta EE e Quarkus.

Col passare del tempo, le aziende vogliono passare da uno stile all'altro per risparmiare denaro o per operare più velocemente. Ma non puoi semplicemente cambiare la vernice. Devi spostare l'intera casa.

La Sfida: Non si tratta solo di cambiare alcune parole. Devi riscrivere come è cablata la casa, come si aprono le porte e come scorre l'acqua, assicurandoti al contempo che la famiglia all'interno non noti alcuna differenza nella propria vita quotidiana.
Lo Stato Attuale: Gli esperti dicono che questo è incredibilmente difficile. Fino ad ora, nessuno aveva un buon modo per testare se l'Intelligenza Artificiale (AI) potesse svolgere questo lavoro.

La Soluzione: SCARFBENCH (Il "Test di Trasloco")

Gli autori hanno creato un enorme test chiamato SCARFBENCH. Immaginalo come un "Simulatore di Trasloco" per il software.

La Preparazione: Hanno preso 34 diverse "case" (applicazioni software) costruite in uno stile (ad esempio, Spring).
L'Obiettivo: Hanno chiesto ad agenti AI (programmi informatici intelligenti) di ricostruire queste stesse identiche case in uno stile diverso (ad esempio, Quarkus o Jakarta), mantenendo la routine quotidiana della famiglia (il comportamento del software) esattamente uguale.
La Prova: Non hanno semplicemente chiesto all'AI: "Hai finito?". Hanno costruito un rigoroso "Esame Orale" (una suite di test). La nuova casa doveva:
- Superare l'ispettore edile (compilare).
- Accendere le luci e l'acqua (distribuire/deployare).
- Permettere alla famiglia di entrare dalla porta d'ingresso, sedersi nel soggiorno e accendere la TV esattamente come facevano prima (superare i test comportamentali).

I Risultati: L'AI Sta Ancora Imparando a Traslocare

I ricercatori hanno testato cinque degli agenti di codifica AI più intelligenti disponibili oggi. Ecco cosa hanno scoperto:

Il Punteggio è Basso: Anche la migliore AI è riuscita a spostare con successo solo circa il 12% al 15% delle case perfettamente.
La Trappola del "Falso Successo": Molte AI sono riuscite a costruire una casa che sembrava buona sulla carta e ad accendere anche le luci (ha compilato e distribuito), ma quando la famiglia ha provato a usarla, le porte non si aprivano o l'acqua non scorreva. L'AI poteva tradurre le parole del progetto, ma non riusciva a comprendere la logica della casa.
Alcuni Traslochi Sono Più Difficili: Spostarsi da uno stile all'altro era più facile in alcuni casi rispetto ad altri. Spostarsi verso lo stile Jakarta è stato il più difficile; l'AI non è riuscita nemmeno a far costruire la casa (compilare) in più della metà dei tentativi.
Un Successo: Su 204 diversi compiti di trasloco, solo uno è stato completato perfettamente da un'AI, dove la nuova casa funzionava esattamente come la vecchia.

Perché Questo È Importante

Questo articolo non dice che l'AI è inutile. Dice che, mentre l'AI sta diventando brava a scrivere codice, è ancora terribile nel ri-progettare sistemi complessi. È come avere un robot che può scrivere una poesia, ma se gli chiedi di spostare l'intera cucina in una nuova casa e di mantenere il frigorifero funzionante, potrebbe mettere il frigorifero in camera da letto.

Gli autori hanno rilasciato questo "Simulatore di Trasloco" (il benchmark) in modo che altri ricercatori possano usarlo per insegnare all'AI come eseguire questi complessi traslochi meglio in futuro. Stanno essenzialmente dicendo: "Ecco un metro di misura; usalo per vedere se la tua nuova AI può effettivamente spostare la casa, non solo dipingere le pareti".

In sintesi: SCARFBENCH è un controllo di realtà. Mostra che, mentre l'AI è eccellente in piccoli compiti, spostare interi sistemi software da un framework moderno a un altro senza romperli è ancora un lavoro che richiede una comprensione a livello umano, e l'AI attuale non è ancora arrivata a quel punto.

Riepilogo Tecnico: SCARFBENCH

Enunciato del Problema

Il Java Enterprise rimane una forza dominante nell'infrastruttura software, con molte applicazioni che sopravvivono alle loro ipotesi architetturali originali. Sebbene la modernizzazione sia spesso guidata da pressioni di deprecazione e obiettivi non funzionali come la riduzione dell'overhead di memoria e una migliore elasticità nel cloud, migrare queste applicazioni tra framework (in particolare tra Spring, Jakarta EE e Quarkus) è un'impresa complessa e soggetta a rischi.

I benchmark attuali di ingegneria del software valutano principalmente la correzione di bug, l'implementazione di funzionalità o gli aggiornamenti delle versioni del linguaggio all'interno di una pila di framework fissa. Essi falliscono in gran parte nel misurare il refactoring di applicazioni cross-framework, un compito che richiede più della semplice sostituzione locale delle API. Una migrazione di successo richiede cambiamenti coordinati nelle configurazioni di build, nell'iniezione delle dipendenze, nella persistenza, nella gestione delle richieste e nel deployment per preservare il comportamento dell'applicazione. I benchmark esistenti spesso assumono che preservare il modello di programmazione sottostante sia sufficiente, un'ipotesi che non regge quando si passa tra framework con modelli di runtime e idiomi divergenti.

Metodologia: SCARFBENCH

Gli autori introducono SCARFBENCH (Self-Contained Application Refactoring Benchmark), un benchmark progettato per valutare la capacità degli agenti di Modelli Linguistici (LLM) di eseguire migrazioni cross-framework che preservano il comportamento.

Costruzione del Benchmark

Ambito: Il benchmark comprende 34 famiglie di applicazioni implementate su tre framework: Spring Boot, Jakarta EE e Quarkus.
Struttura: È suddiviso in due livelli:
1. Livello Focalizzato: 29 applicazioni autonome che isolano specifici strati architetturali (Iniezione delle Dipendenze, Persistenza, Presentazione, Infrastruttura, Dominio Aziendale) ancorati alle Java Specification Requests (JSR).
2. Livello Applicazione Intera: 5 sistemi open-source più grandi e realistici che combinano questi strati, testando l'accoppiamento tra livelli e i flussi di lavoro end-to-end.
Varianti: Queste applicazioni generano 102 varianti specifiche per framework (circa 151K righe di codice Java accoppiato attraverso 1.946 file sorgente e di test).
Compiti: Il benchmark definisce 204 compiti di migrazione diretti (ad esempio, Spring $\to$ Jakarta, Jakarta $\to$ Quarkus). Ogni compito richiede a un agente di sintetizzare un'implementazione target che preservi il comportamento sorgente.
Verità di Base: Sviluppatori Java esperti hanno implementato manualmente tutte e tre le varianti di framework per ogni famiglia di applicazioni, garantendo l'esistenza di implementazioni comportamentalmente equivalenti per la validazione.

Protocollo di Valutazione

Agenti: Sono stati valutati cinque agenti di codifica all'avanguardia: Claude Code (Opus 4.6), Gemini CLI (Gemini-3.1 Pro), Codex (GPT-5.4), Opencode (GLM-5.1) e Qwen CLI (Qwen3.5-397B-A17B).
Strumento di Esecuzione: Un ambiente containerizzato valuta i candidati in tre fasi sequenziali:
1. Compilazione: Il candidato deve compilare con successo.
2. Deployment: L'applicazione deve avviarsi all'interno di un runtime containerizzato ed emettere segnali di prontezza.
3. Test Comportamentali: Il candidato deve superare una suite di 1.331 test comportamentali scritti da esperti.
Oracolo: La correttezza è determinata da un oracolo comportamentale neutrale rispetto al framework. Invece di test unitari (che richiederebbero essi stessi una migrazione), l'oracolo utilizza specifiche Gherkin concretizzate in script Playwright/pytest. Questi test verificano l'equivalenza osservabile esternamente (route HTTP, payload di risposta, flussi UI e modifiche allo stato persistente).
Metriche: Il successo è misurato da pass@1 a temperatura 0, richiedendo che il candidato compili, si distribuisca e superi il 100% dei test comportamentali.

Contributi Chiave

Dataset SCARFBENCH: Un corpus curato di 34 famiglie di applicazioni che genera 102 varianti e 204 compiti di migrazione diretti, verificati da 1.331 test comportamentali scritti da esperti in un ambiente containerizzato.
Valutazione Empirica: Una valutazione completa di cinque agenti di codifica all'avanguardia, che rivela significativi gap nelle capacità attuali per le trasformazioni a livello di sistema.
Tassonomia degli Errori: Una classificazione di 13 categorie ricorrenti di fallimento che coprono le fasi di build, deploy e test, derivata dalla valutazione esperta delle tracce di fallimento.

Risultati Sperimentali

La valutazione rivela che la migrazione di framework che preserva il comportamento rimane una sfida significativa per gli agenti attuali:

Bassi Tassi di Successo: L'agente più forte (Claude Code con Opus 4.6) ha raggiunto solo il 15,3% di passaggi aggregati nei test per le migrazioni a livello focalizzato e il 12,2% per le applicazioni intere. Su tutti i 204 compiti diretti, solo una migrazione prodotta da un agente ha superato la sua suite completa di test.
Build/Deploy vs Comportamento: Esiste una netta disconnessione tra il successo superficiale e la correttezza comportamentale. Gli agenti producono frequentemente codice che compila e si distribuisce ma fallisce i test comportamentali. Ad esempio, nelle migrazioni di applicazioni intere, il successo della compilazione può raggiungere l'87% mentre il successo comportamentale scende al 12%.
Difficoltà Asimmetrica: La difficoltà di migrazione dipende fortemente dal framework target:
- Spring $\leftrightarrow$ Quarkus: La coppia più gestibile.
- Target Jakarta EE: La più difficile. Solo il 2% delle migrazioni con target Jakarta EE supera i test comportamentali, con il 57% che fallisce alla porta di compilazione.
Prompt Engineering: Il prompting basato su "competenze" (modularizzazione delle indicazioni) ha migliorato i tassi di compilazione e deployment, in particolare per i compiti focalizzati, ma non ha chiuso significativamente il gap nella correttezza comportamentale per le applicazioni intere.

Analisi dei Fallimenti

L'analisi dei compiti falliti ha identificato che gli errori vanno oltre la traduzione a livello di sorgente. Le modalità di fallimento comuni includono:

Fase Build: Problemi di risoluzione delle dipendenze, riferimenti a moduli obsoleti e discrepanze nella struttura del progetto.
Fase Deploy: Disallineamenti di risorse/artefatti (ad esempio, packaging WAR vs JAR), configurazione di runtime errata (ad esempio, mismatch delle porte) e cablaggio delle dipendenze interrotto.
Fase Test: Endpoint mancanti, contenuto di risposta errato e problemi di connettività dell'infrastruttura.
Gli autori notano che le migrazioni con target Jakarta falliscono in modo sproporzionato alla porta di compilazione, suggerendo una divergenza tra gli idiomi di framework appresi e le convenzioni di packaging e configurazione del server di Jakarta.

Significato e Affermazioni

Il paper afferma che, sebbene gli agenti attuali possano tradurre in modo affidabile le API dei framework a livello di sorgente, faticano a riformulare il comportamento dell'applicazione attraverso il modello di runtime del framework target. I risultati suggeriscono che i progressi sui benchmark a livello di repository (come la correzione di bug o gli aggiornamenti di versione) non si trasferiscono in modo pulito alle trasformazioni a livello di sistema che richiedono l'esecuzione in un runtime target.

Gli autori posizionano SCARFBENCH come un passo necessario verso la valutazione delle capacità "agentiche" degli LLM in scenari aziendali realistici, evidenziando che la vera modernizzazione richiede più della sostituzione sintattica; essa esige una profonda comprensione dell'accoppiamento architetturale, della semantica della configurazione e della preservazione comportamentale. Il benchmark, l'ambiente di esecuzione e le tracce degli agenti sono rilasciati per facilitare ulteriori ricerche sulla modernizzazione automatizzata del software.