Oracle 禁止 AI 生成代码进入 OpenJDK:同一家公司为何给 GraalVM 开绿灯

开源AIJava

Oracle 与 OpenJDK 的 AI 代码禁令

2026 年 4 月 9 日,OpenJDK 管理委员会批准了一项临时政策,全面禁止在社区贡献中使用 AI 生成的内容。这项政策的措辞极为宽泛:贡献者不得提交任何由大语言模型、扩散模型或类似深度学习系统"部分或全部"生成的源代码、文本或图片。涵盖范围从 Git 仓库和 GitHub PR,延伸到邮件列表、Wiki 页面甚至 Java Bug System(JBS)工单。

政策的三重理由

OpenJDK 官方页面列出了三个核心关切。

第一,审查者负担。AI 工具擅长批量生成"看起来合理"的代码和测试,但这些代码即使正确,设计质量也往往堪忧,难以维护。审查这类提交会消耗本就稀缺的人力审查时间。OpenJDK 明确指出,已有多个开源社区因同样原因限制或禁止 AI 生成代码的提交。

第二,安全与可靠性。JDK 是 Java 平台的主实现,运行在全球企业、政府和其他组织的关键任务系统中。"安全是重中之重。看起来合理但实际错误的代码会危及这些关键属性。"

第三,知识产权。Oracle Contributor Agreement(OCA)要求贡献者拥有其贡献的全部知识产权,并能不受限制地授予 Oracle。但大多数生成式 AI 工具在受版权保护的许可内容上训练,其输出可能包含侵犯这些版权和许可的内容。贡献这类内容将违反 OCA。OpenJDK 政策指出,AI 工具用户是否对其生成的输出拥有知识产权,"目前正处于积极诉讼中"。

禁令的边界:私有使用豁免

政策并非完全禁止使用 AI 工具。贡献者可以"私有地"使用大语言模型来理解、调试和审查 OpenJDK 代码,进行与 OpenJDK 项目相关的研究——只要不将工具生成的内容作为贡献提交。

FAQ 对此做了进一步澄清:

  • 使用 AI 工具生成 100 行代码然后手动编辑其中 10 行,仍然不允许提交,因为贡献中仍包含 AI 生成的代码
  • IDE 中的拼写检查、语法检查、自动补全和重构功能可以使用,前提是它们不基于大语言模型或类似深度学习系统
  • 用 AI 工具审查自己手写的 JEP 草案、JavaDoc 或其他文档可以,这属于"审查内容"而非"生成内容"
  • 在 OpenJDK 项目中添加调用外部 AI 服务的功能需要咨询律师,因为许多服务条款对使用方式有严格限制

OpenJDK 正在重新配置 Skara(自动化 PR 审查系统),为每个 GitHub PR 添加一个复选框,贡献者创建 PR 时必须勾选确认贡献符合 AI 政策。

检测困境

OpenJDK 坦承,"可靠地区分人类生成内容和 AI 生成内容是不可能的"。政策要求审查者留意 AI 生成内容的特征线索:

  • 提交信息中包含 Co-Authored-By trailer,将功劳归于某个 AI 工具
  • 评论风格与贡献者过往的写作风格不一致,表现为比平常更健谈、冗长
  • 高度结构化的多标题注释、代码中不必要的注释、过度防御性编程
  • 使用 emoji 字符

政策同时承认:"AI 工具正在快速进化,今天有效的线索明天可能就不再有效。如果一个 PR 中的某些内容看起来异常欢快或异常精细,你可能正在看 AI 生成的内容。"

Oracle 的内部矛盾:OpenJDK 禁止,GraalVM 允许

政策最引人注目的地方在于 Oracle 内部的立场分裂。GraalVM 是 Oracle Labs 旗下项目,使用与 OpenJDK 相同的 OCA 协议,但不受 OpenJDK 管理委员会管辖。2026 年 4 月中旬,GraalVM 发布了截然相反的 AI 辅助贡献政策,明确允许生成式 AI 内容:

GraalVM 贡献者在使用 AI 编码助手和类似工具准备贡献时可以使用这些工具。"编码助手"包括帮助起草、转换、解释、审查或总结代码、测试、文档或提交文本的 AI 工具。

GraalVM 的政策参考了 Linux 内核的 AI Coding Assistants 政策,但做了弱化调整。Linux 内核要求贡献包含 Assisted-by 标签;GraalVM 则说"显式归属于特定模型或工具是可选的",但"鼓励在帮助审查者理解变更如何产生时披露 AI 辅助"。

GraalVM 的核心原则是贡献者问责制:人类提交者对整个贡献负责,包括 AI 辅助的任何部分。必须审查和理解代码、验证正确性、回答审查者的问题,不能将责任推给工具。"如果贡献者无法解释、辩护或维护一个 AI 辅助的变更,该贡献可能被拒绝。"

同一份 OCA,同一个 Oracle,两个项目做出了相反的选择。OpenJDK 将 IP 风险视为禁止的充分理由;GraalVM 将贡献者问责视为允许的充分理由。

Larry Ellison 的悖论

Oracle 对 OpenJDK 贡献者的严格要求与公司内部对 AI 代码的拥抱形成鲜明对比。CTO Larry Ellison 在 Oracle AI World 2025 上说:

"Oracle 正在写的代码,不是 Oracle 写的。是我们的 AI 模型在写。我们只告诉模型我们想让程序做什么,然后 AI 会想出一个逐步的过程来实际执行它。我们不写过程。我们声明意图,但模型写那个逐步过程;也就是我们通常认为的计算机程序。"

联合 CEO Mike Sicilia 在 2026 年 3 月表示:"AI 工具及其编码能力如果不去采用就会成为威胁,但我们正在非常迅速地采用。Oracle 内部使用 AI 编码工具使得更小的工程团队能够更快地向客户交付更完整的解决方案。"

Oracle 同时在 6 月以 AI 部署为由裁减了 21,000 个工作岗位,并宣布未来一年投入 700 亿美元建设数据中心(高于上一财年的 557 亿美元)。标普随即将 Oracle 信用评级下调至 BBB-,仅比垃圾级高一档。

四大开源项目的 AI 代码政策光谱

OpenJDK 并非第一个直面 AI 代码问题的开源项目。2025 至 2026 年间,Linux 内核、GCC、OpenJDK、Rust 相继出台了正式政策,构成了一个从"全面拥抱"到"全面禁止"的光谱。

Linux 内核(2025 年 5 月):由 Linus Torvalds 和维护者团队制定的 coding-assistants.rst 是最务实的方案。AI 代理不得添加 Signed-off-by 标签——只有人类才能合法认证 Developer Certificate of Origin(DCO)。人类提交者负责审查所有 AI 生成代码、确保许可合规、添加自己的 Signed-off-by 标签。AI 辅助的贡献应包含 Assisted-by 标签,格式为 Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]。这个标签既是透明度机制也是审查标记,让维护者知道哪些 patch 需要额外审查。

GCC:在 Linux 内核之后、OpenJDK 之前实施了类似的限制政策。

OpenJDK(2026 年 4 月):全面禁止。最严格的方案。部分 AI 生成也不行,手动修改后仍不行。

Rust(2026 年 8 月 5 日):五个团队在 rust-lang/rust 仓库采纳了 Jynn Nelson 撰写的 LLM 政策。指导原则是一句话:"可以用 LLM 回答问题、分析、提炼、精修、检查、建议、审查。但不能用来创建。"任何以你名字发布的、由 LLM 撰写的内容都必须披露。机器翻译、"琐碎"修改、发现 bug、用 LLM 审查他人工作都要求披露。LLM 创建的代码变更规则极其严格:必须是预先安排的、非关键的、高质量的、充分测试且充分审查的,并附有披露。Rust 政策的起草过程经历了数月内部辩论,PR 收到了 65 条 issue 评论和 284 条审查评论。

项目立场AI 生成代码标记要求
Linux 内核允许(有条件)允许,人类负全责Assisted-by 标签
GraalVM允许允许,贡献者问责披露鼓励但不强制
Rust限制严格条件下允许强制披露
GCC限制限制-
OpenJDK禁止完全禁止无(不适用)

开发者影响

对于使用 AI 编码工具的 Java 开发者,OpenJDK 政策意味着:

  • 可以用 ChatGPT、Claude 或 Copilot 帮助理解 OpenJDK 源码、调试问题、做代码审查
  • 不可以把 AI 生成的代码、测试、文档或注释放入任何 OpenJDK 贡献
  • 不可以让 AI 写代码然后手动调整(仍包含 AI 生成部分)
  • 可以继续使用 IDE 中非 LLM 的自动补全、重构等功能
  • 必须在创建 PR 时勾选确认框,声明贡献符合 AI 政策

这项政策是临时的。Oracle 表示正在起草完整的 AI 贡献政策,将"适时"提交给 OpenJDK 管理委员会。但截至 2026 年 8 月,完整政策尚未公开。

版权诉讼的阴影

OpenJDK 政策中提到的"AI 生成输出的知识产权归属正处于积极诉讼中",指的是一系列正在进行的法律案件。AI 训练数据的版权问题(如 The New York Times 诉 OpenAI、Getty Images 诉 Stability AI)尚未有最终判决。在这些案件尘埃落定之前,Oracle 选择最保守的路径——全面禁止,而非冒险接受可能侵权的内容。

HN 社区的讨论中,用户 skwirl 指出了一个深层动因:Oracle 在知识产权诉讼方面有重大商业利益。如果 Oracle 在 OpenJDK 中允许使用 LLM 生成的代码,可能会在未来的版权诉讼中削弱自己的立场。Oracle 需要保留起诉任何生成可能基于其版权材料训练的软件的权利。

这种法律策略式的保守主义与 GraalVM 的务实主义形成了鲜明对比。同一个法律团队起草的同一份 OCA,在不同项目中被解读出两种截然相反的含义。


来源: