Java基础、中级、高级、架构面试资料

Java 的 OpenJDK 全面禁止 AI 生成代码

JAVA herman 15浏览
公告:“业余草”微信公众号 AI 中转站提供免费体验,点击链接 https://unity2.ai/register?ref=3XTnndN2 进行访问,支持 Claude、ChatGPT、Gemini 等最新模型!关注业余草微信公众号,添加作者微信:xttblog2!
本博客日IP超过2000,PV 3000 左右,急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包,请加博主新的微信号:xttblog2,之前的微信号好友位已满,备注:返现
受密码保护的文章请关注“业余草”公众号,回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽,请关注文末小程序
视频教程免费领
【腾讯云】1核2G5M轻量应用服务器50元首年,高性价比,助您轻松上云

AI 的发展太快了,但 AI 的治理还没有跟上。

这导致一些开源项目拥抱 AI,一些开源项目“封杀” AI。甚至是不同的群体对 AI 的支持和反对情况也不一样。

前段时间,我在文章里也提了一嘴 Linux 和 Gcc 等开源项目对 AI 编程的支持情况,昨天又看到了 Java 的东家 Oracle 再次明确新规,OpenJDK 全面禁止 AI 生成代码。

Oracle 可以说是“双标王”。一方面宣称由于 AI 等进行减员,包括 MySQL 和 Java 团队等;另一方面在 OpenJDK 项目上,又通过新规全面禁止 AI 生成的代码。

感觉有些拧巴,下面我们一起来扯一扯这个重磅新规的“前因后果”。

OpenJDK 对 AI 生成代码说不

2026 年 4 月,OpenJDK 社区发布了一份名为 《OpenJDK Interim Policy on Generative AI》(OpenJDK 生成式 AI 临时政策)的文件,在 Java 生态乃至整个开源界投下了一枚重磅炸弹。

这份政策的措辞极为严厉:

OpenJDK 社区的贡献不得包含由大语言模型、扩散模型或类似深度学习系统生成的内容,无论部分还是全部

细看内容,覆盖范围之广令人侧目。这里面的内容不仅包括源代码,还包括文本、图片,涵盖 Git 仓库、GitHub Pull Request、邮件、Wiki 页面、JBS(Java Bug System)Issue 等所有社区沟通渠道。

更“狠”的是,政策 FAQ 中明确回答了一个尖锐问题:“如果我用 AI 生成了 100 行代码,然后自己修改了 10 行,可以提交吗?

官方的答案是不行。只要贡献中包含任何 AI 生成的内容,无论比例多少,一律禁止。

不过,政策并非“一刀切”地封杀 AI。OpenJDK 明确鼓励开发者“私下”使用生成式 AI 工具来理解、调试、审查现有代码,以及进行与 OpenJDK 项目相关的研究。

说白了,你可以用 AI 学习,但不能把 AI 的产物交上去。

文章配图参见我的公众号:https://mp.weixin.qq.com/s/rd4CQ5oyGzsDuLZA16AzUQ

OpenJDK 为什么要这么做?

官方在政策中给出了三条理由,每一条都直指大型开源项目的核心痛点,但我认为最主要的一条或一点是知识产权

下面我们稍微展开看看。

审查者负担

官方说,生成式 AI 让编写“看起来合理”的代码变得异常容易。问题是,这些代码往往“看起来有模有样,测试也过得去,但设计上存在缺陷,或者根本就是错的”。

OpenJDK 的维护者时间极其有限。当大量 AI 辅助的 PR 涌入时,“过滤掉哪怕明显有问题的那些,也是一种消耗”。一位 Hacker News 用户的评论被官方 FAQ 引用,精准地描述了这一困境。

这不是杞人忧天。New Relic 2026 年的一份报告显示,AI 生成的代码在审查中往往获得比人类代码更高的评分,但“生产环境中的故障率却在上升”。“看起来对,实际错”,“看起来好,实际坏”(looks good, breaks things)已经成为一个真实存在的模式。

JDK 不是试验场

JDK 是全球无数关键任务系统的基石,包括:银行、电信、政府、医疗等核心关键系统。

因此,OpenJDK 在 FAQ 中毫不含糊地指出:

安全和可靠性至关重要。看起来合理但实际错误的代码会直接危及这些关键属性

对于承载全球基础设施的代码库,任何不确定性都是不可接受的。OpenJDK 不能成为 AI 代码质量的试验场。

其它语言不知道怎么看,就只有 Java 关键嘛🤣。

知识产权

AI 生成的内容面临版权“黑洞”。这是最关键、也最具法律风险的一条。

OpenJDK 的贡献者必须签署 Oracle Contributor Agreement(OCA),该协议要求贡献者拥有其每一次贡献的知识产权,并能够无限制地将这些权利授予 Oracle。

但问题是,大多数生成式 AI 工具都是在受版权保护的内容上训练的,其输出可能包含侵犯这些版权和许可的内容。而用户是否对 AI 生成的内容拥有知识产权,目前在大多数司法管辖区仍是正在诉讼中的未决问题

对 Oracle 这样一家在 Java 知识产权上有着激进诉讼历史的公司来说,保持 OpenJDK 每一行代码的来源清晰、可辩护,是至关重要的。

Oracle 也“双标”

其内部拥抱 AI,开源却禁 AI。

因此,这条政策最讽刺的地方在于,它与 Oracle 公司内部的实践形成了鲜明的、甚至可以说是荒诞的对比

Oracle 联合创始人兼 CTO Larry Ellison 在 2025 年的 Oracle AI World 上公开宣称:

Oracle 写的代码,Oracle 不是在写。我们的 AI 模型在写。我们只是告诉模型我们想要程序做什么,然后 AI 会想出一步一步实际执行的过程。我们不写程序。我们声明意图,但模型写程序

Oracle 联席 CEO Mike Sicilia 也在今年早些时候表示:

AI 编码工具的使用正在让更小的工程团队能够更快地向客户交付更完整的解决方案

Oracle 甚至将 AI 作为减员的理由。今年 6 月,Oracle 宣布裁去部分员工约 21000 人,声明中称“AI 技术在我们运营中的部署已经导致、并可能继续导致员工数量的减少”。

一边在公司内部全力拥抱 AI 写代码,甚至为此裁员;一边在管理的开源项目中全面禁止 AI 生成代码。这种“双标”引发了外网的广泛嘲讽。

英国科技媒体 The Register 的标题也极具讽刺意味。

As Larry Ellison bets the farm, Oracle says it loves AI-written code, just not in OpenJDK

翻译过来,大致意思就是说:Larry Ellison 押上全部身家,Oracle 却说它热爱 AI 写的代码,只是不能在 OpenJDK 里。

文章很尖锐,讨论了不少核心尖锐的问题,但这就是 Oracle。

OpenJDK vs GraalVM

另一个更耐人寻味的是,Oracle 旗下的另一个重要开源项目 GraalVM,却采取了与 OpenJDK 完全相反的立场。

GraalVM 的编码助手政策明确允许贡献者使用 AI 工具准备贡献,并认为“负责任地使用这些工具应该提高开发速度并改善质量”。其核心条件是:提交更改的人必须对整个贡献负责,必须理解并能够捍卫每一行代码。如果做不到,更改就会被拒绝。

这一政策明显受到了 Linux 内核的启发,Linus Torvalds 的项目同样允许 AI 辅助,但强调人的责任。

同一个 Oracle,同一个 OCA(贡献者协议),却有两种截然相反的政策。OpenJDK 说“任何形式的 AI 生成代码都别提交”,GraalVM 说“可以用,但你要负全责”。

正如 JVM Weekly 的分析所言,这不是矛盾,而是反映了不同项目的风险画像:

  • OpenJDK 是全球关键系统的平台基础,有严格的 OCA 流程,外部贡献者数量庞大、水平参差不齐;
  • GraalVM 是一个更小的项目,社区更专业,维护者更了解他们的贡献者。

但这种对比依然令人震惊,它说明“即使在同一个公司生态内,对于 AI 代码的态度也没有统一答案”。

其他开源项目怎么做?

OpenJDK 并非孤例。现在我们放眼整个开源世界,看看各大开源项目目前对 AI 代码的态度,显示出正在分化。

项目/社区政策
OpenJDK全面禁止 AI 生成内容
QEMU类似禁令
GCC禁止 LLM 编写的贡献
Gentoo禁止 AI 辅助代码贡献
NetBSD将 AI 生成代码视为版权违规
SDL禁止 LLM 生成的代码贡献
Linux 内核允许,但贡献者负全责
GraalVM允许,但贡献者负全责
Apache允许,但有条件
Debian讨论中,尚未决定

这种分裂揭示了一个根本性的行业困境。AI 工具每天都在改变我们写代码的方式,但开源社区对于 AI 代码的治理,连统一的答案都没有,哪怕在同一个生态系统内

结语

OpenJDK 的 AI 禁令,本质上是一份 AI 与开源社区的“婚前协议”,在双方正式“结合”之前,先把风险边界划清楚。

Oracle 的“双标”固然值得嘲讽,但从另一个角度看,它也揭示了一个现实。企业可以在内部承担 AI 代码的风险(并从中获益),但不愿意将这些风险转嫁给开源社区和下游用户

对于开发者而言,这提醒我们,AI 是强大的工具,但不是免责的借口。无论政策如何变化,对自己提交的每一行代码负责,始终是工程师的基本职业素养。

正如 GraalVM 的政策所言,如果你不能解释、捍卫或维护一个 AI 辅助的更改,那么这个更改就应该被拒绝。这句话,或许比任何禁令都更接近问题的本质。

结合我前几天的那篇文章,AI 提交的代码,如果发生了生产事故,责任人依旧是程序员,尤其是那个提交代码的程序员。

业余草公众号

最后,欢迎关注我的个人微信公众号:业余草(yyucao)!可加作者微信号:xttblog2。备注:“1”,添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注!后续有精彩内容会第一时间发给您!原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系!

本文原文出处:业余草: » Java 的 OpenJDK 全面禁止 AI 生成代码