编译 | 苏宓出品 | CSDNIDCSDNnews近日Oracle 针对 OpenJDK 贡献者发布了一项新规禁止提交由 AI 生成的代码。这并非一项建议而是一条硬性要求。作为 Java 的参考实现、并支撑着全球大量企业级软件的核心基础设施OpenJDK 的这一决定迅速引发了外界对 AI 生成代码的讨论。除此之外更令人疑惑的是制定这项规则的 Oracle自己却在积极拥抱 AI 编程并公开强调 AI 正在改变软件开发方式。一边是对 AI 编程的积极拥抱另一边却对 AI 生成代码设下限制这种看似矛盾的态度也难免引发众人关注。这项政策到底说了什么在这份名为《OpenJDK 关于生成式 AI 的临时政策》声明中Oracle 说的非常直白OpenJDK 社区中的贡献不得包含任何由大型语言模型LLM、扩散模型或类似深度学习系统部分或全部生成的内容。这里所说的“内容”包括但不限于OpenJDK Git 仓库中的源代码、文本和图像以及 GitHub Pull Request、电子邮件、Wiki 页面和 JBS Issue 中的相关内容。不过Oracle 并不是完全禁止开发者使用 AI 工具。Oracle 指出OpenJDK 社区的贡献者可以私下使用生成式 AI 工具帮助理解、调试和审查 OpenJDK 代码及其他内容也可以利用这些工具开展与 OpenJDK 项目相关的研究但前提是不得将这些工具生成的内容贡献到 OpenJDK 社区。对此有开发者 Kanishk Singh 整理了这套规则下的贡献流程贡献者必须勾选确认提交内容合规合并请求才会进入人工审核流程。Contributors local workflow OpenJDK contribution pipeline ┌───────────────────────┐ ┌─────────────────────────┐ │ AI used privately to │ │ Pull request opened │ │ explain,debug,research│ ───────► │ │ │ └───────────────────────┘ │ ▼ │ │Skara compliance checkbox│ Human writes and owns the ─────────►│ (not AI-generated) │ actual submitted code │ │ │ │ ▼ │ │ Human reviewer │ │ │ │ │ ▼ │ │ Merge │ └─────────────────────────┘之所以这么做Oracle 给出的理由包括如果直接使用 AI 生成的代码会增加代码审核负担、安全风险以及 AI 生成内容尚未解决的知识产权归属问题。Oracle 着重强调OpenJDK 支撑着全球大量关键业务系统。在这种情况下看起来正确但隐藏细微错误的代码会带来另一种风险——尤其是在代码审查者往往无法可靠判断某次修改究竟来自人类还是 AI 自动生成时。关于 AI 使用Oracle 自己内部并没有统一答案让这件事变得耐人寻味的地方在于同一时期Oracle 旗下另一个开源项目采取了完全不同的态度。其中由 Oracle Labs 推动的 GraalVM 项目此前发布的 Coding Assistants 政策明确允许 AI 辅助贡献。但它设置的门槛并非一刀切禁止而是设立责任制度无论是否借助 AI贡献者必须能够解释、论证、长期维护自己提交的所有代码这一政策鼓励主动披露 AI 参与情况但不作强制要求。也就是说同一家企业内部两个开源项目面对同一类潜在风险制定了截然相反的规则OpenJDK 选择全面禁止 AI 生成代码GraalVM 选择 “可以自由使用 AI但贡献者全权负责”。两种方案从工程角度都具备合理性但放在一起很难让人认为 Oracle 对 AI 代码已经形成统一、成熟的立场。这种矛盾在 Oracle 管理层过去公开表达的观点衬托下更加明显。在 2025 年 Oracle AI World 大会上Oracle 联合创始人兼 CTO Larry Ellison 曾表示Oracle 内部的软件开发已经不再真正意义上是“写代码”。工程师只需要描述他们希望程序实现什么功能而模型会生成具体的实现步骤。Oracle 联席 CEO 也曾多次强调公司正在快速采用 AI 编程工具并将其视为保持竞争力的必要手段而不是需要回避的风险。为什么这项政策引发关注严格来说Oracle 对 OpenJDK 实施 AI 代码禁令并不是毫无道理。代码审查能力、安全问题以及 AI 输出的知识产权来源不明确确实是所有大型开源项目都需要面对的问题。许多其他重要开源项目也都在讨论类似问题。但真正引发争议的是这项政策背后隐藏的信息一家最积极推动 AI 编写生产级代码的公司却决定对于自己最重要的基础设施项目仍然要求每一行代码背后必须有人承担责任。这与 Oracle 目前大举押注 AI 的做法多少有些矛盾。如今Oracle 正投入数百亿美元建设 AI 数据中心基础设施但这笔巨额投资能否带来预期回报仍存在不确定性公司也因此面临信用评级压力。今年早些时候Oracle 还曾将 AI 的快速发展作为调整员工结构的因素之一。对于那些正在开发 AI 编程工具的团队来说这或许才是这项政策最值得关注的地方Oracle 并不是反对 AI 编程而是说明了一件事——即使是一家正在大力押注 AI 的公司也不认为 AI 生成的代码可以在没有人工审核和负责人的情况下直接进入关键软件项目。来源https://openjdk.org/legal/aihttps://medium.com/kanishks772/oracle-just-banned-ai-code-from-openjdk-the-reason-is-going-to-upset-ai-developers-bc577ee7c73d
编译 | 苏宓出品 | CSDNIDCSDNnews近日Oracle 针对 OpenJDK 贡献者发布了一项新规禁止提交由 AI 生成的代码。这并非一项建议而是一条硬性要求。作为 Java 的参考实现、并支撑着全球大量企业级软件的核心基础设施OpenJDK 的这一决定迅速引发了外界对 AI 生成代码的讨论。除此之外更令人疑惑的是制定这项规则的 Oracle自己却在积极拥抱 AI 编程并公开强调 AI 正在改变软件开发方式。一边是对 AI 编程的积极拥抱另一边却对 AI 生成代码设下限制这种看似矛盾的态度也难免引发众人关注。这项政策到底说了什么在这份名为《OpenJDK 关于生成式 AI 的临时政策》声明中Oracle 说的非常直白OpenJDK 社区中的贡献不得包含任何由大型语言模型LLM、扩散模型或类似深度学习系统部分或全部生成的内容。这里所说的“内容”包括但不限于OpenJDK Git 仓库中的源代码、文本和图像以及 GitHub Pull Request、电子邮件、Wiki 页面和 JBS Issue 中的相关内容。不过Oracle 并不是完全禁止开发者使用 AI 工具。Oracle 指出OpenJDK 社区的贡献者可以私下使用生成式 AI 工具帮助理解、调试和审查 OpenJDK 代码及其他内容也可以利用这些工具开展与 OpenJDK 项目相关的研究但前提是不得将这些工具生成的内容贡献到 OpenJDK 社区。对此有开发者 Kanishk Singh 整理了这套规则下的贡献流程贡献者必须勾选确认提交内容合规合并请求才会进入人工审核流程。Contributors local workflow OpenJDK contribution pipeline ┌───────────────────────┐ ┌─────────────────────────┐ │ AI used privately to │ │ Pull request opened │ │ explain,debug,research│ ───────► │ │ │ └───────────────────────┘ │ ▼ │ │Skara compliance checkbox│ Human writes and owns the ─────────►│ (not AI-generated) │ actual submitted code │ │ │ │ ▼ │ │ Human reviewer │ │ │ │ │ ▼ │ │ Merge │ └─────────────────────────┘之所以这么做Oracle 给出的理由包括如果直接使用 AI 生成的代码会增加代码审核负担、安全风险以及 AI 生成内容尚未解决的知识产权归属问题。Oracle 着重强调OpenJDK 支撑着全球大量关键业务系统。在这种情况下看起来正确但隐藏细微错误的代码会带来另一种风险——尤其是在代码审查者往往无法可靠判断某次修改究竟来自人类还是 AI 自动生成时。关于 AI 使用Oracle 自己内部并没有统一答案让这件事变得耐人寻味的地方在于同一时期Oracle 旗下另一个开源项目采取了完全不同的态度。其中由 Oracle Labs 推动的 GraalVM 项目此前发布的 Coding Assistants 政策明确允许 AI 辅助贡献。但它设置的门槛并非一刀切禁止而是设立责任制度无论是否借助 AI贡献者必须能够解释、论证、长期维护自己提交的所有代码这一政策鼓励主动披露 AI 参与情况但不作强制要求。也就是说同一家企业内部两个开源项目面对同一类潜在风险制定了截然相反的规则OpenJDK 选择全面禁止 AI 生成代码GraalVM 选择 “可以自由使用 AI但贡献者全权负责”。两种方案从工程角度都具备合理性但放在一起很难让人认为 Oracle 对 AI 代码已经形成统一、成熟的立场。这种矛盾在 Oracle 管理层过去公开表达的观点衬托下更加明显。在 2025 年 Oracle AI World 大会上Oracle 联合创始人兼 CTO Larry Ellison 曾表示Oracle 内部的软件开发已经不再真正意义上是“写代码”。工程师只需要描述他们希望程序实现什么功能而模型会生成具体的实现步骤。Oracle 联席 CEO 也曾多次强调公司正在快速采用 AI 编程工具并将其视为保持竞争力的必要手段而不是需要回避的风险。为什么这项政策引发关注严格来说Oracle 对 OpenJDK 实施 AI 代码禁令并不是毫无道理。代码审查能力、安全问题以及 AI 输出的知识产权来源不明确确实是所有大型开源项目都需要面对的问题。许多其他重要开源项目也都在讨论类似问题。但真正引发争议的是这项政策背后隐藏的信息一家最积极推动 AI 编写生产级代码的公司却决定对于自己最重要的基础设施项目仍然要求每一行代码背后必须有人承担责任。这与 Oracle 目前大举押注 AI 的做法多少有些矛盾。如今Oracle 正投入数百亿美元建设 AI 数据中心基础设施但这笔巨额投资能否带来预期回报仍存在不确定性公司也因此面临信用评级压力。今年早些时候Oracle 还曾将 AI 的快速发展作为调整员工结构的因素之一。对于那些正在开发 AI 编程工具的团队来说这或许才是这项政策最值得关注的地方Oracle 并不是反对 AI 编程而是说明了一件事——即使是一家正在大力押注 AI 的公司也不认为 AI 生成的代码可以在没有人工审核和负责人的情况下直接进入关键软件项目。来源https://openjdk.org/legal/aihttps://medium.com/kanishks772/oracle-just-banned-ai-code-from-openjdk-the-reason-is-going-to-upset-ai-developers-bc577ee7c73d
