OpenJDK bans AI-generated code in upstream contributions, and the new interim policy covers source code, text, and images in OpenJDK Git repositories, on GitHub pull requests, in email, on wiki pages, and in JBS issues. The OpenJDK Governing Board approved the rule while Oracle drafts a full policy. In the meantime, contributors who submit anything produced, in part or in full, by large language models, diffusion models, or similar deep learning systems are out of compliance.

The policy page, published on openjdk.org, is short and direct: "Contributions in the OpenJDK Community must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems." That includes source code, tests, documentation, and even images in the project's Git repositories. The ban extends to GitHub pull requests, email messages, wiki pages, and Java Bug System (JBS) issues.

Why OpenJDK drew this line

The interim policy page lists three risks: reviewer burden, safety and security, and intellectual property.

Reviewer burden is the one every maintainer recognizes. Generative AI makes it easy to produce large volumes of plausible-looking code with plausible-looking tests, code that is nonetheless incorrect, or correct but poorly designed. The page says reviewing such submissions "can easily become a drain on the already limited time of human reviewers." Several other open source communities have already limited or banned AI submissions for the same reason.

Safety and security follow from the role OpenJDK plays. The JDK sits at the foundation of mission-critical systems in businesses and governments. "Plausible-looking but incorrect code would put these critical properties at risk," the FAQ states.

Intellectual property is the most technical reason, and it is the one most likely to outlive the interim period. The Oracle Contributor Agreement (OCA) requires contributors to own the intellectual property rights in their work and to grant those rights to Oracle without restriction. AI training data includes copyrighted and licensed content, and outputs can infringe those rights. Whether a user has rights in AI-generated content is the subject of active litigation, so OpenJDK does not want to accept that risk in its codebase.

What is still allowed

The policy is careful not to ban AI tools outright. It says contributors can use generative AI privately to "comprehend, debug, and review OpenJDK code and other content, and to do research related to OpenJDK Projects," as long as they do not contribute what the tools generate.

That split is where the workflow questions begin. The policy permits:

• Using AI to help understand existing code before editing.
• Using AI to debug or review your own work.
• Using spellcheckers and grammar checkers, plus auto-completion and refactoring features in an IDE, as long as those features are not powered by large language models or similar deep-learning systems.
• Using a generative AI tool to review a draft JEP or Javadoc text, only the human writes every word of the final text.

Editing machine output does not make it human-derived. One FAQ example is explicit. If an AI tool creates 100 lines of code and a contributor edits 10 of them by hand, the contribution is still banned because "your contribution would still include, in part, AI-generated code."

How it will be enforced

Enforcement is mostly self-attested at first. The OpenJDK team will reconfigure Skara, the project's tooling around GitHub, to add a checkbox to the body of every pull request. Contributors must check the box to affirm the contribution "is in accordance with the policy."

Reviewers are not expected to become AI detectors. The FAQ acknowledges that "reliably distinguishing human-generated content from AI-generated content is impossible." The obligation is narrower: if a reviewer sees evidence that a contribution used a generative AI tool, they should notify the contributor, and if the contributor does not remove the content, the reviewer brings it to the attention of the Project Lead.

The Oracle contrast: bets the farm on AI

The policy landed at an awkward time for Oracle's public affairs. On August 3, The Register published "As Larry Ellison bets the farm, Oracle says it loves AI-written code, just not in OpenJDK."

That is not a rhetorical mismatch invented by a reporter. Oracle's own messaging takes a different tone. At Oracle AI World 2025, co-founder and CTO Larry Ellison described how Oracle now builds software: "The code that Oracle is writing, Oracle isn't writing," he said. "Our AI models are writing. We just tell the model what we want the program to do, and then the AI comes up with a step-by-step process to actually do it." Co-CEO Mike Sicilia echoed the same in March 2026, saying the use of AI coding tools inside Oracle is "enabling smaller engineering teams to deliver more complete solutions to our customers more quickly."

Oracle also cut 21,000 jobs in June 2026 and cited "Deployment of AI technologies across our operations" in the statement. And it said last month it would invest $70 billion in the coming year to finance its datacenter build-out, up from $55.7 billion in fiscal 2026. S&P responded by downgrading Oracle's credit rating to BBB-, one notch above junk status, citing an uncertain path to profitability on those investments.

None of that means the OpenJDK policy is wrong. It just makes the policy read differently: a corporate sponsor asking external contributors to hold a bar that its own engineering organization does not appear to follow, at least publicly.

Community reaction

The Hacker News thread (435 points as of August 7) split into roughly two camps. One sees it as license and IP defense: Oracle cannot risk third-party code in a codebase it licenses under GPLv2, and AI training data has unresolved copyright questions (the FAQ itself cites active litigation). The other camp flagged the irony of "rules for thee." Some developers will adapt by generating code, then rewriting it line by line so it counts as human-authored. The policy does not address that, and honestly, it cannot detect the difference.

What this means for Java developers

If you contribute to OpenJDK, read the official policy at openjdk.org/legal/ai before your next pull request. The practical steps:

1. Do not submit code, docs, or text from any LLM as part of a JDK change, including small pieces.
2. Keep AI tools for comprehension, debugging, and review of planned PRs.
3. If your IDE auto-complete has a local LLM behind it, be aware it counts as AI-generated in part, and adjust the code manually.
4. Expect the Skara checkbox on the PR form. Existing PRs need to pass policy too.
5. If you are uncertain about a project feature that calls an external AI service, the docs say consult a lawyer, because terms-of-use restrictions can block or break a planned feature.

For everyone else, this is another data point in the running experiment: open source as a legal pressure test of AI-generated code. Whatever Oracle's motives, the policy gives maintainers around the world a written playbook for keeping generated code out of a foundational project.

Frequently Asked Questions

Does the ban apply to code committed outside OpenJDK? No. It applies to OpenJDK Community contributions: repositories, pull requests, issues, mailing lists, wiki pages.

Can I still use AI to write my Javadoc? No. You may use AI to review your own written text, but the text itself must be human-authored. AI-generated documentation is treated like AI-generated code.

What is Skara? The OpenJDK tooling integrates the JDK with GitHub. It will add a checkbox to PRs affirming the contribution complies with the policy.

Is this interim or permanent? Interim. Oracle (as corporate sponsor) is drafting the full policy and will propose it to the OpenJDK Governing Board.

Does Oracle follow this in its own code? In OpenJDK's subordinate repos, yes. Its internal engineering, as portrayed publicly, uses AI models to write code. That contrast is exactly why the policy is drawing attention.

Key Takeaways

• OpenJDK now bans contributions containing LLM-generated content, including edited output that still contains generated code.
• The three cited reasons: reviewer burden, safety/security, and intellectual property risk under the OCA.
• AI tools remain allowed for private comprehension, debugging, review, and research; IDE features based on LLMs count as generative.
• Reviewers are not AI detectors, but they must flag visible evidence and escalate to the Project Lead.
• Oracle's own AI-writing messaging and its OpenJDK ban create a visible conflict for contributors.

---

Sources: OpenJDK Interim Policy on Generative AI, The Register: Oracle says it loves AI-written code, just not in OpenJDK, Hacker News discussion