💻 computer science

MigrationBench: Repository-Level Code Migration Benchmark from Java 8

本文介绍了 MigrationBench，这是一个用于将 Java 8 代码迁移至现代长期支持版本（17 和 21）的全方位仓库级基准测试与评估框架，结果表明智能体大语言模型框架能够在此项极具挑战性的任务中实现高成功率。

原作者： Linbo Liu, Xinle Liu, Qiang Zhou, Lin Chen, Yihan Liu, Hoan Nguyen, Behrooz Omidvar-Tehrani, Xi Shen, Jun Huan, Omer Tripp, Anoop Deoras

发布于 2026-05-29

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Linbo Liu, Xinle Liu, Qiang Zhou, Lin Chen, Yihan Liu, Hoan Nguyen, Behrooz Omidvar-Tehrani, Xi Shen, Jun Huan, Omer Tripp, Anoop Deoras

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你拥有一座巨大的古老图书馆，里面藏满了用一种特定、略显过时的英语风格（我们称之为“英语 8"）写成的书籍。这座图书馆规模宏大，藏书成千上万，且每一本书目前都处于完美状态。

现在，想象图书馆董事会决定将整个建筑升级到一种全新的现代标准（“英语 17"）。这不仅仅是更换字体；而是要更新语法规则、词汇以及书籍的组织方式，以便它们能与新建筑的安全系统和电梯协同工作。

MigrationBench 是由 AWS AI 的研究人员创建的一项巨大挑战，旨在测试人工智能（特别是大型语言模型或 LLM）处理这项大规模翻新项目的表现。

以下是他们工作的分解，采用简单的类比：

1. 问题：搬迁整座城市，而非仅仅一栋房子

大多数以往的人工智能测试，就像是要求机器人修复一个漏水的水龙头或撰写一个段落。但现实世界的软件并非只有一个文件；它是一个由相互连接的建筑物（即“代码仓库”）组成的整座城市。

挑战：从“英语 8"迁移到“英语 17"需要同时更改数千个文件。如果你更改了一个路标，可能会导致三个街区外的交通信号灯失灵。
差距：直到现在，还没有一个标准化的“考试”来评估人工智能是否能够在不导致整个系统崩溃的情况下，完成整个代码城市的翻新工作。

2. 解决方案："MigrationBench"数据集

研究人员构建了一个名为 MigrationBench 的大型测试套件。

完整数据集：他们从互联网（如 GitHub）上收集了 5,102 个真实的开源 Java 项目。他们对这些项目进行了筛选，确保它们质量高、拥有适当的许可证，并且目前运行完美。
“精选”子集：测试所有 5000 多个项目耗时太久。因此，他们亲手挑选了 300 个最复杂、最棘手且最有趣的项目。你可以将此视为数据集的“期末考试”版本，旨在对人工智能进行真正的压力测试。

3. 游戏规则（评估标准）

如何判断翻新是否成功？研究人员设定了两个难度等级：

等级 1：最小化迁移（“能运行”测试）
- 目标：人工智能只需确保代码能够编译（构建），并且所有现有测试在新版本中都能通过。
- 类比：建筑物是安全的，灯光亮起，电梯运行正常。书籍可读。
- 成功率：使用他们最佳的人工智能配置，在此处的成功率为 71.67%。
等级 2：最大化迁移（“现代化”测试）
- 目标：人工智能不仅要确保代码能运行，还必须将代码内部的每一个工具和库升级到绝对最新、最安全的版本。
- 类比：不仅建筑物是安全的，人工智能还更换了所有旧管道为新的铜管，将监控摄像头更新为 4K 分辨率，并安装了最新的智能家居功能。这要困难得多，因为新工具通常有不同的规则。
- 成功率：这要严峻得多。最佳的人工智能配置在此处的成功率为 53.33%。

4. 工作者：人工智能代理

研究人员并没有仅仅要求人工智能“编写代码”。他们构建了 人工智能代理——配备工具的数字化员工。

基础员工：一个简单的人工智能，查看代码并尝试修复错误。它在处理“最大化”升级时遇到了困难。
智能员工（提示工程）：他们为基础员工提供了一套更好的指令，明确指示其升级所有内容。这大有裨益。
研究员工（RAG）：他们为员工提供了一本最新软件版本的“电话簿”（知识库），使其无需猜测。这进一步改善了结果。
混合团队（获胜者）：这是最巧妙的方案。他们使用计算机程序自动用新工具替换旧工具（一个快速、机械化的步骤），然后让人工智能代理介入，修复新工具无法完美契合的混乱部分。
- 结果：该团队的表现与最昂贵的人工智能员工相当，但使用了 11% 更少 的计算资源。

5. 结果

该论文表明，虽然人工智能在修复小型代码问题方面变得越来越擅长，但将整个软件“城市”从旧版本翻新到新版本仍然是一项巨大的挑战。

混合方法（结合自动化工具与人工智能）被证明是执行此任务最高效的方式。
该数据集以及这些人工智能代理的代码现已公开，其他研究人员可以尝试构建更优秀的翻新团队。

简而言之：MigrationBench 是一个全新、严格的人工智能健身房，用于练习将整个软件库从旧版本迁移到新版本。它表明，虽然人工智能具备能力，但最复杂的“翻新”工作仍然需要自动化工具与类人推理的智能结合，才能将工作圆满完成。

技术摘要：MigrationBench

问题陈述

尽管大语言模型（LLM）在代码生成和孤立问题修复方面已展现出显著成功，但其在仓库级代码迁移方面的能力仍评估不足。与仅关注单个函数或文件的任务不同，代码迁移需要一种整体性方法来处理整个代码库中相互关联的问题，特别是在升级遗留系统时。具体而言，目前缺乏旨在评估将 Java 8 仓库迁移至现代长期支持（LTS）版本（Java 17 和 21）的大规模、高质量基准数据集。现有的基准测试往往侧重于代码生成、语言间翻译或小规模维护任务，未能捕捉涉及数千行代码和复杂依赖树的真实世界迁移场景的复杂性和规模。

方法论

1. 数据集构建（MigrationBench）

作者引入了MigrationBench，这是首个用于 Java 仓库迁移的大规模基准。数据集的构建过程涉及对 GitHub 仓库应用严格的、多步骤的过滤管道：

初始过滤： 根据许可证（MIT/Apache 2.0）、质量（至少 3 颗星）和构建工具（Maven）对仓库进行过滤。
兼容性验证： 团队为每个仓库确定了一个“基础提交”（ $H_b$ ），在该提交下代码能够在 Java 8 环境下成功构建并通过测试。这包括验证 pom.xml 配置，确保没有与目标不兼容的硬编码 Java 8 版本，并验证编译后的类主版本号为 52（Java 8）。
去重： 基于文件哈希和内容的完全匹配对仓库进行去重。
测试要求： 将仓库划分为Full数据集（5,102 个包含单元测试的仓库）和UTG子集（4,814 个无测试的仓库）。Full 数据集作为迁移评估的主要基准。
选定子集： 从 Full 数据集中精心挑选了 300 个仓库的代表性子集（selected）。该子集侧重于更大规模、多模块的仓库，以更好地反映真实世界迁移挑战的多样性和复杂性。

2. 评估框架

由于缺乏真实的目标仓库作为基准，作者提出了一个基于**近似功能等价性（FE）**的自动化评估框架：

最小化迁移： 由以下四个标准定义：
1. 构建成功： 在 Java 17 环境下 mvn clean verify 通过。
2. 版本验证： 编译后的类主版本号为 61（Java 17）。
3. 测试方法不变性： 测试方法（标注为 @Test）未被重命名、禁用或删除（通过 AST 解析验证）。
4. 测试数量不变性： 测试用例数量未减少。
最大化迁移： 在最小化迁移的基础上增加第五个标准：
1. 依赖现代化： 所有依赖项均升级至 Maven Central 上可用的最新稳定主版本（截至 2024 年 11 月）。

3. 智能体框架

本文使用Strands 智能体框架和Claude-4.5-Sonnet评估了多种基于智能体的方法：

基线（Strands 智能体）： 配备 Shell 和编辑工具以迁移代码并确保 mvn clean verify 通过。
提示工程（PE）智能体： 通过系统提示增强，明确指示智能体将所有依赖项升级至其最新的主版本。
RAG 智能体： 结合检索增强生成（RAG）方法，智能体查询外部依赖知识库以识别正确的最新版本。
混合方法： 结合静态代码分析（确定性升级依赖项）与 LLM 智能体。静态工具处理版本升级，智能体修复由此产生的构建失败和兼容性问题。

主要贡献

MigrationBench 数据集： 引入了首个用于仓库级代码迁移的大规模基准，包含 5,102 个仓库（Full）和一个精心挑选的 300 个仓库子集（Selected）。
评估框架： 一个全面的自动化框架，通过最小化和最大化标准评估迁移成功，解决了迁移任务中缺乏真实基准的问题。
智能体解决方案： 提出并评估了用于代码迁移的智能体工作流，包括一种新颖的混合方法，该方法结合静态分析与 LLM 推理以提高效率。
开放资源： 发布数据集、评估源代码以及详细的智能体轨迹（包括中间决策和失败模式），以支持可复现性和未来研究。

实验结果

实验在selected子集（300 个仓库）上进行，使用 Strands 智能体框架和 Claude-4.5-Sonnet。

最小化迁移： 基线 Strands 智能体在最小化迁移中实现了**71.67%**的成功率（pass@1）。
最大化迁移：
- 基线智能体仅实现了**15.33%**的成功率。
- 添加提示工程（PE）将有效性提升至45.67%。
- 结合 RAG 进一步将有效性提升至53.33%。
- 混合方法达到了与 RAG 智能体相同的**53.33%**有效性，同时减少了每个仓库的平均 LLM 调用次数（52.55 对 59.22），展示了有利的成本效益权衡。
模型比较： 当将混合方法应用于其他模型（DeepSeek-V3.1、Qwen3-Coder-480B、GLM-5）时，Claude-4.5-Sonnet 仍然最有效，尽管其他模型也显示出不同程度的成功（例如，GLM-5 达到了 45.33%）。
编译与验证： 禁用单元测试（仅依赖 mvn clean compile）将最小化迁移的有效性从 71.67% 提高到 97.67%，突显了测试套件在验证功能等价性中的关键作用。

意义与主张

本文将 MigrationBench 定位为推动软件工程和 LLM 能力研究的关键资源。作者主张：

复杂性差距： 迁移任务比代码生成或孤立问题修复呈现出显著更高的难度级别，需要整体性的仓库理解。
可行性： LLM，特别是在智能体工作流和外部知识（RAG）或混合静态分析的引导下，可以有效解决从 Java 8 到 Java 17 的仓库级迁移。
标准化： 提出的评估框架提供了一种严格、标准化的迁移成功评估方法，超越了简单的编译检查，纳入了依赖现代化和测试保留。
未来方向： 智能体轨迹和 UTG 子集的发布为研究智能体局限性、失败模式以及为遗留代码生成单元测试开辟了新的途径。

作者承认存在的局限性，包括对现有测试覆盖率的依赖（这可能无法保证未测试代码的完全功能等价性），以及由于大规模数据收集期间 Maven Central 的限流而可能导致的可复现性问题。然而，他们坚持认为 MigrationBench 为代码迁移方法的系统化和可复现性评估提供了坚实的基础。