Oracle Bans AI-Generated Code for OpenJDK. But Is It Sustainable?

Code generation, debugging, testing, and documentation can now be compressed from hours to minutes, thanks to Claude Code, Codex, and an endless array of AI-powered tools. 

But in the open-source ecosystem, that efficiency has created a problem. The cost of producing code is falling much faster than the cost of reviewing and maintaining it.

Over the past several months, open source projects and maintainer communities have been grappling with a growing stream of AI-assisted and AI-generated contributions. 

In April, Oracle added one of the clearest restrictions yet to that debate. The company, which sponsors the OpenJDK Community, published an interim policy stating that contributions to OpenJDK “must not include content generated, in part or in full,” by large language models, diffusion models or similar deep-learning systems.

That covers more than source code. The restriction extends to text and images submitted through OpenJDK’s Git repositories, GitHub pull requests, emails, wiki pages, and issue tracker. 

Contributors can still use generative AI privately to understand, debug, and review OpenJDK code, or to conduct research, but they cannot contribute content generated by those systems.

While OpenJDK is not arguing against AI’s use in software development, it is drawing a line between using AI as a tool for understanding existing code and using it to create material that becomes part of the project itself.

And that line opens a much larger question for open source: when AI can generate the contribution, who carries the cost of verifying it, who is responsible when it is wrong, and who can legally attest to where that code came from?

Over the last few months, this has left developers divided over whether AI provenance should itself disqualify a contribution.

How Hard is it to Enforce Human Responsibility? 

“I believe that Oracle/OpenJDK is taking this restrictive position for intellectual property reasons — and not due to reviewer burden, safety, or security of OpenJDK,” says Sai Rahul Poruri, CEO of FOSS United, in an interaction with AIM.

“I say so because the Linux Kernel is as foundational as Java/OpenJDK is, but they are still accepting AI-assisted code contributions.”

Poruri is not arguing that projects should accept unchecked AI output. He says AI-generated patches from first-time contributors without human oversight can carry significant risks. His objection is to treating AI assistance itself as the disqualifying factor when projects such as the Linux kernel have instead built accountability into the contribution process.

The Linux kernel now requires contributors to disclose meaningful tool-generated content, explain which tools were used, and how the contribution was tested. The human submitter must understand and defend the entire submission and personally add the ‘Signed-off-by’ tag under the Developer Certificate of Origin, but AI agents cannot do so. 

Maintainers can also demand additional testing or scrutiny, or reject the contribution altogether.

Other projects have adopted similar, but not identical, approaches. LLVM permits AI-assisted contributions subject to human review and disclosure. 

Ironically, GraalVM, another Oracle-owned open-source JDK, explicitly allows AI-assisted contributions and places responsibility for the entire submission on the human contributor.

A recent report from The Register also pointed to another irony. 

Oracle’s chairman and CTO Larry Ellison has been among the company’s strongest advocates for an AI-driven future, arguing that AI will eventually “automatically write” the code and programs that run sales, legal, and other business processes. But can projects reliably distinguish AI-generated code from AI-assisted code?

Poruri believes they can.

An AI-generated contribution, he argues, is likely to be “one-shotted”: a contributor feeds a feature request into a coding model, takes the resulting implementation, and opens a pull request with little effort to adapt it to the project's conventions.

“The AI-assisted code, on the other hand, will appear much more granular, for example, in the Pull request as numerous commits,” Poruri says. “The user methodically breaks down the feature request and uses a code-generating AI to address smaller code blocks.”

At each stage, the contributor can test the output, check it against project standards and make the necessary changes before moving on. Tools that attach AI attribution to commits can also provide maintainers with a record of where AI entered the development process.

The Enforcement Problem

Pratik Ambhore, Head of Data Engineering at R Systems, argues that the key issue should be accountability, rather than whether AI was involved in producing the code. He views OpenJDK’s ban as a legitimate interim risk-management measure but not a sustainable long-term model, even as Oracle continues to work on a broader, permanent policy governing generative AI contributions to OpenJDK. 

The bigger challenge, he says, is enforcing the boundary between AI-assisted and AI-generated code. 

Once the generated output is reviewed, modified, and integrated into a larger contribution, determining exactly where AI involvement ends becomes unreliable. “The longer-term approach should be ‘trust, but validate’,” Ambhore says, with disclosure of material AI use, clear human accountability, and stricter review for security- and runtime-critical changes.

OpenJDK’s policy also places a significant burden on human contributors and reviewers to establish whether a contribution complies with its AI rules. But delegating that enforcement to coding agents is not yet reliable either.

A study from Peking University last month tested four coding-agent/model combinations—OpenCode with DeepSeek-V4-Pro, Codex with GPT-5.3-Codex, Codex with GPT-5.5, and Claude Code with Claude Sonnet 4.6—across 106 tasks drawn from 49 repositories with AI-contribution rules.

The agents proactively opened the relevant policy files in just 3.5% of unaided runs. More importantly, all four recorded a 0% compliance rate for rules requiring them to refuse AI-banned contributions.

In other words, even explicit rules are difficult to enforce consistently. That raises a different question: rather than trying to keep AI out, can projects make its use visible and hold contributors accountable for the result?

Move From ‘Anti AI’ to ‘Anti AI Slop’ 

“An outright ban on AI is like a dam holding back an ocean. The productivity gains are simply too massive for the industry to ignore,” says Sathya Narayanan AG, a software engineer with over two decades of experience at companies like Google, Oracle, BT, and Virtusa.

Rather than banning AI, Narayanan argues that open-source projects should introduce friction where human accountability matters. 

He explains an “issue before code” model, which would require contributors to articulate and discuss a problem before submitting a PR, making low-effort, AI-generated contributions harder to produce while giving maintainers a record of genuine engagement. OpenRefine has explored a similar approach that ties contributions to issues.

He also proposes a “show your work” model, where contributors disclose the AI tools and prompts they used and explain the technical decisions behind the resulting code. The aim is not to establish whether AI touched the code, but whether the contributor understands and can defend it.

“As an industry, there must be a clear shift towards code lineage tracking. Every AI-assisted contribution should carry a provenance tag, so maintainers know exactly what was generated versus what was human-engineered,” Narayanan says.

His argument is to move from an “anti-AI” stance to an “anti-AI-slop” one, which retains AI’s productivity gains while making human responsibility and code provenance explicit.