The story hit the Hacker News front page again this week: Oracle bans AI-generated code from OpenJDK. 536 points, 381 comments, and a comment section full of people arguing about a policy most of them had apparently not read. I have run AI coding agents as a core part of my daily workflow for a long time now, so my first reaction was the same as probably yours: a blanket ban? In 2026? For Java, the language running half the world's banks?
Then I actually read the OpenJDK Interim Policy on Generative AI, and it is a much more interesting document than the headline suggests. It is not an anti-AI manifesto. It draws a very specific line, it explicitly blesses an entire category of AI use, and it closes every loophole the FAQ could think of. Whether you agree with it or not, if you write Java and you use AI tools, the difference between the allowed side and the banned side of that line is worth ten minutes of your time.
Full disclosure: I have never contributed to OpenJDK, and I am not a lawyer. Everything below comes from the policy itself, the InfoQ analysis by Karsten Silz, The Register's coverage, and the Hacker News threads. Where something is my opinion rather than a sourced fact, I say so.
What the policy actually says
The core rule, approved by the OpenJDK Governing Board on April 9, 2026, is one sentence:
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.
Three details in that sentence do most of the work.
- "In part or in full" kills the edit-a-little loophole. The FAQ asks the obvious follow-up: if an AI generates 100 lines and you hand-edit ten, can you contribute the result? The answer is a flat "No." The contribution is still partly AI-generated. There is no percentage threshold, no substantial-transformation test.
- "Content" is much wider than code. The ban covers source code, text, and images across Git repositories, GitHub pull requests, email messages, wiki pages, and Java Bug System issues. If an LLM drafted your bug report, that bug report violates the policy. An autonomous AI agent cannot even file an issue, let alone a patch.
- It covers every OpenJDK project channel, not just the JDK itself, because "the OpenJDK Community" is the scope, not one repository.
Enforcement runs through Skara, OpenJDK's pull request tooling, which adds a checkbox every contributor must tick to affirm compliance. The policy also admits the honest limitation: it says that reliably distinguishing human-generated from AI-generated content is impossible. The checkbox is an attestation, not a detector. Tick it falsely and the liability trail points at you.
What is explicitly allowed
This is the part the headlines skip, and it is bigger than most people expect.
- Reading, debugging, and reviewing with AI is fine. You may use generative AI privately to comprehend OpenJDK code, debug it, review it, and research changes. The policy even agrees with the folks who say this is where the tools shine: the FAQ notes that analysis of existing code is where generative AI performs best on large, established codebases.
- AI as a document reviewer is fine. The FAQ states you can have a generative AI tool review your draft JEP or JavaDoc, as long as every word you submit is written by you.
- Non-LLM automation is fine. Spell-checking, grammar-checking, auto-completion, and refactoring features are allowed so long as they are not based on large language models or similar systems. Classic IDE refactoring: welcome. Copilot-style completions: not in the jdk checkout.
So the shape of the rule is not "no AI." It is: AI may read, but AI may not write anything that enters the project. Read-only AI is explicitly encouraged. Write-path AI is banned at a threshold of one line.
The three reasons, and which one is real
The policy lists three risks. They are not equally weighted, and figuring out which one is doing the real work explains most of the apparent weirdness.
- Reviewer burden. Maintainers are a scarce shared resource, and floods of plausible-looking but incorrect code drain them. Real, but it does not explain banning AI-written bug report prose.
- Safety and security. OpenJDK calls itself the primary Java implementation for mission-critical systems worldwide, and plausible-looking but incorrect code would put that at risk. Real, but the same argument applies to every mature project, and most of them did not choose a total ban.
- Intellectual property. Here is the one that bites. The Oracle Contributor Agreement requires that a contributor own the IP rights in what they submit and grant them to Oracle without restriction. The policy points out that most generative tools are trained on copyrighted material, their output can reproduce it, and whether a user even holds IP rights in generated output is, in its own words, "the subject of active litigation." You cannot grant rights you may not have.
That third reason is why the ban is absolute rather than disclosure-based, and why the enforcement is a legal checkbox rather than a detection system. A company that spent a decade litigating the copyright status of Java all the way to the Supreme Court is not going to volunteer for round two over a tainted patch.
The GraalVM problem, and the Ellison quote
Now for the part that made this story explode.
GraalVM, developed by Oracle Labs, published its own coding assistants policy in mid-April 2026, days after the OpenJDK ban. It runs the other way: contributors may use AI coding assistants to draft, transform, explain, review, and summarize code, tests, documentation, and commit text. Attribution is optional. The anchor is accountability: if you cannot explain, defend, and maintain your AI-assisted change in review, it gets rejected. And GraalVM contributors sign the exact same Oracle Contributor Agreement as OpenJDK contributors.
Same company, same legal agreement, opposite rule. As InfoQ put it, OpenJDK treats unclear IP exposure as grounds for prohibition while GraalVM treats contributor accountability as sufficient grounds for permission.
Then there is Larry Ellison. At Oracle AI World, Oracle's co-founder and CTO said, about Oracle's own software: "The code that Oracle is writing, Oracle isn't writing. Our AI models are writing." The Register's headline wrote itself: Oracle bans AI-generated code from OpenJDK despite Ellison's claim that Oracle isn't writing its own code.
Here is my read of the apparent hypocrisy, and I think it dissolves more than it looks like it should. When Oracle's own employees generate code with company-sanctioned tools, Oracle owns the output and absorbs whatever copyright risk exists, full stop. When an outside volunteer submits a patch to GPL-licensed code Oracle also ships commercially, that risk would flow through the contributor's attestation into Oracle's reference implementation of Java. The ban is not an anti-AI conviction. It is risk asymmetry. GraalVM proves the point: where Oracle controls the whole pipeline, it is perfectly comfortable with AI-written code.
It is also worth knowing this is not a novel position. Gentoo banned AI-generated contributions back in April 2024. NetBSD followed within weeks, treating LLM output as presumptively tainted. QEMU adopted its own prohibition in 2025. OpenJDK is the biggest and most corporate project to join the prohibition camp, and it arrived while parts of the ecosystem, like the Linux kernel and LLVM, were settling on the opposite norm: disclose the tool, review the output, own the result.
If you ever contribute to OpenJDK: the compliant workflow
I have not contributed to OpenJDK myself, so treat this as the workflow the policy text implies rather than a battle report. It is also a decent checklist for any prohibition-camp project, because Gentoo, NetBSD, and QEMU have similar rules.
- Partition your tools by repo, not by intention. LLM-based autocomplete stays off in the jdk checkout, and that includes IDE built-ins that call cloud models. The policy grandfathers only non-LLM features: classic refactoring, spell-check, grammar-check.
- Keep the assistant in a separate window. Using AI to understand a foreign subsystem, debug a crash, or research how an existing JEP solved a problem is explicitly blessed. That is the highest-value use of AI on a 30-year-old codebase anyway, and OpenJDK says so.
- Audit your commit messages. Many agent tools add a "Co-Authored-By" trailer by default, and reviewers are encouraged to watch for exactly that kind of tell. A trailer your tooling added without your knowledge is the policy's canonical smoking gun.
- Write every submitted word yourself. Code, comments, commit messages, bug reports, mailing list prose. You can paste your draft JEP into a model and ask for critique. You cannot paste the model's suggested rewrite into the JEP.
- Tick the Skara checkbox honestly. The policy cannot reliably detect violations, by its own admission. That checkbox is what turns an undetectable violation into a documented false attestation if you get it wrong.
What I would watch next
The policy is labeled interim, pending a full policy Oracle has promised "in due course," and my prediction, for what it is worth, is that the permanent version lands much closer to GraalVM's accountability model than to this ban. The pressure will not come from hobbyists; it will come from corporate contributors at Red Hat, SAP, Amazon, and Azul whose employers now mandate AI-assisted development internally and who need carve-outs to keep contributing upstream. Blanket bans also depend on detection heuristics that everyone involved knows are unreliable. The disclosure-and-own-it model is the only one that survives a world where the tooling ships in every editor.
Until then, the durable idea in this policy is worth stealing regardless of what you think of the ban: there is a real difference between AI as a reading tool and AI as a writing tool, and the reading side is where most of the value lives anyway. OpenJDK just happens to be the first project big enough to write the distinction into law.
I write about Java, AI tooling, and the developer ecosystem every week. Subscribe, it is free.
Which side of this do you land on: is OpenJDK being responsibly cautious with the world's most load-bearing Java code, or is a checkbox-and-honor-system ban that cannot detect violations just theater? Have you ever had an AI tool slip something into a commit message without you noticing? Tell me in the comments.
Quick reference checklist: the OpenJDK AI rules at a glance
- Banned: any contribution containing AI-generated content, in part or in full. One edited line out of a hundred still counts as AI-generated.
- Banned everywhere: code, PRs, emails, wiki pages, JBS issues. An AI agent cannot even file a bug report.
- Allowed: using AI privately to comprehend, debug, review, and research OpenJDK code.
- Allowed: AI review of your draft JEPs or JavaDoc, as long as you write every submitted word.
- Allowed: spell-check, grammar-check, autocomplete, and refactoring tools that are not LLM-based.
- Enforcement: a Skara checkbox attesting compliance, plus reviewer vigilance for tell-tale signs.
- Status: interim, approved April 9, 2026. A full policy is promised but has no published timeline.
- The GraalVM exception: same company, same contributor agreement, AI assistants explicitly welcome under an accountability standard.
Sources:
Top comments (0)