Oracle bans AI-generated code from OpenJDK contributions under an interim policy the OpenJDK Governing Board put in place in April 2026. The ban covers source code, documentation, pull requests, emails, wiki edits, and bug reports — anywhere a contributor submits work to the project.
Short answer: Oracle bans AI-generated code from OpenJDK. The policy at openjdk.org/legal/ai prohibits content "generated, in part or in full" by LLMs or similar tools in any OpenJDK contribution — code, docs, PRs, or bug reports. Reviewers cite reviewer burden, security risk in mission-critical infrastructure, and unresolved IP ownership over AI output. Private AI use for debugging is still fine.
I went through the actual policy text and the two follow-up reports that dug into it, because "Oracle bans AI code" was getting flattened into a much bigger claim than what's written down. It's not a company-wide ban. It's a contribution rule for one specific open source project Oracle sponsors, and Oracle's other JVM project takes the opposite position.
What you need to know first
OpenJDK is the open source reference implementation of Java. Oracle is its corporate sponsor. Every contributor signs the Oracle Contributor Agreement (OCA) before code lands in the repository. In April 2026, the OpenJDK Governing Board adopted an Interim Policy on Generative AI that bars any content generated, in whole or in part, by large language models, diffusion models, or similar deep-learning systems from being submitted to the project. That's the entire scope: contributions in, not tool use in general. If you never intended to send a patch to OpenJDK, none of this changes what's on your laptop.
Step-by-step: what the OpenJDK policy actually restricts
1. Know what counts as a "contribution"
The policy isn't limited to .java files. It names source code, text, and images across OpenJDK Git repositories, GitHub pull requests, mailing list messages, wiki pages, and Java Bug System (JBS) issues. Writing an AI-assisted bug report counts the same as submitting an AI-assisted patch.
2. Understand the "partial" rule
This is the part contributors get wrong most often. The policy's own FAQ gives the example directly: editing 10 lines of a 100-line AI-generated function does not make the contribution acceptable, because it's still partly AI-generated. There's no threshold where a small enough AI contribution slips through.
3. Check the compliance step in Skara
OpenJDK's contribution tooling, Skara, requires a compliance confirmation before a patch is accepted — contributors attest the submission contains no generative AI content. It's a process gate, not an honor-system suggestion.
4. Know what's still allowed
You can still run an LLM locally to debug a stack trace, ask it to explain an unfamiliar part of the JDK codebase, or use it to review your own draft before you write the real patch by hand. The restriction is on what you submit, not on what tools sit on your own machine while you think through the problem.
5. See why Oracle drew the line here specifically
The policy gives three reasons. First, reviewer burden: a flood of plausible-looking but subtly wrong AI code drains the limited volunteer and Oracle reviewer time the project has. Second, safety and security: the JDK runs inside banks, telecoms, and government systems. The board says that demands a higher bar than typical AI-assisted review can clear today. Third, intellectual property. The OCA requires contributors to own the IP rights they grant to Oracle outright. Whether a person holds clean IP rights over an LLM's output is, in the policy's own words, "the subject of active litigation."
Example prompts you can copy (for the AI use that's still allowed)
These are prompts I use for the private, pre-submission use the OpenJDK policy leaves open — understanding code, not generating the patch itself:
- Explain, don't generate: "Explain what this JDK method does and why it might throw here. Don't rewrite it — I'm going to write the fix myself."
- Debug a stack trace: "Here's a stack trace from a failing OpenJDK test. Walk me through the likely cause so I can investigate the real source."
- Self-review before submitting: "Review this patch I wrote by hand for style and edge cases. List concerns only — don't rewrite any of it."
- Draft a bug report from your own notes: "Turn these rough notes into a clear bug report structure, but I'll rewrite every sentence in my own words before I file it, since AI-drafted JBS issues aren't allowed."
Common mistakes to avoid
In my testing of how contributors are actually interpreting this, the most common mistake is assuming a light AI edit is safe because "I mostly wrote it myself." The FAQ's 10-of-100-lines example exists precisely to close that loophole — the rule is about origin, not proportion. The second mistake is confusing OpenJDK's policy with a general Oracle stance. GraalVM, also sponsored by Oracle, explicitly permits AI-assisted contributions as long as the human contributor stays accountable for every line. Treating the two projects as one policy gets contributors in trouble on the stricter one. Third, some assume the ban covers private tool use — it doesn't. You can still run Copilot or Claude locally; you just can't send its output into a PR. Last, don't skip the Skara compliance step assuming it's a formality — it's the actual enforcement point, and a false attestation is a bigger problem than a rejected patch.
OpenJDK vs. GraalVM: same sponsor, opposite rules
| OpenJDK | GraalVM | |
|---|---|---|
| Generative AI in contributions | Banned outright | Allowed |
| Partial AI edits | Not allowed, even minor | Allowed, with disclosure encouraged |
| Contributor responsibility | N/A — AI content excluded entirely | Full responsibility for verifying/defending AI-assisted changes |
| Tool attribution | N/A | Optional but encouraged |
| Policy adopted | April 2026 | Mid-April 2026 |
| Oracle Contributor Agreement | Required | Required |
Both projects sit under the same corporate sponsor and the same OCA, and they landed in opposite places within weeks of each other. OpenJDK treats the IP uncertainty as grounds to exclude AI content entirely; GraalVM treats the same uncertainty as something a human contributor can absorb by staying accountable for what they submit.
Tools that make this easier
If you're a Java contributor trying to figure out where AI still fits in your workflow, the honest answer is: everywhere except the actual patch you submit to OpenJDK. My AI coding assistant guide covers which tools are worth using for the private debugging and review work the policy still allows. If you're choosing between assistants for that role, my Cursor vs. Copilot comparison and GitHub Copilot vs. ChatGPT breakdown cover where each is strongest for reading and explaining unfamiliar code rather than generating it wholesale. If Copilot is already in your editor, my guide on using Copilot inside VS Code walks through dialing it back to suggestion-only mode instead of full generation. My honest review of AI programming tools is the wider context on where these tools actually save time versus where they just create review debt — which is exactly the reviewer-burden argument OpenJDK is making. And if your interest here is really about controlling AI coding costs and governance at a team level rather than open source policy specifically, my piece on how Databricks cut its AI coding spend covers the enterprise side of the same accountability problem.
My take
I don't think this is Oracle being anti-AI. Larry Ellison told Oracle's own AI World audience that Oracle's models now write Oracle's code — "we declare our intent, but the model writes the step-by-step procedure," as The Register reported — and co-CEO Mike Sicilia has credited AI tools with letting smaller engineering teams ship faster. That's the opposite instinct from what OpenJDK just wrote into policy.
My read: OpenJDK is a security-critical dependency for a huge share of the internet's backend. It's reviewed largely by volunteers. It's making a narrower, defensible call. The IP question alone is reason enough to wait rather than find out the hard way. GraalVM, a newer, more contained project, made a different bet. If you contribute to either, read the specific project's policy. Don't assume Oracle's stance is one thing.
Frequently Asked Questions
Does Oracle ban AI-generated code everywhere, or just in OpenJDK?
Just in OpenJDK contributions. GraalVM, another Oracle-sponsored JVM project, explicitly allows AI-assisted contributions as long as the human contributor verifies and takes responsibility for the code. Oracle's own internal engineering also uses AI tools extensively, according to comments from co-founder Larry Ellison and co-CEO Mike Sicilia.
Can I still use Copilot or ChatGPT while working on OpenJDK code?
Yes, privately. The policy restricts what you submit to the project — source code, docs, PRs, emails, wiki edits, and bug reports — not what tools you use on your own machine to understand code or debug an issue before you write the real patch yourself.
What happens if I submit a patch that's only partly AI-generated?
It's still not allowed. The policy's FAQ specifically states that editing 10 of 100 AI-generated lines doesn't make a contribution acceptable, because the contribution remains partly AI-generated. There's no minimum-edit threshold that makes it compliant.
Why did Oracle ban it in OpenJDK but allow it in GraalVM?
The stated reasons for OpenJDK's ban are reviewer burden, the security stakes of a dependency used in mission-critical systems, and unresolved intellectual property questions about who owns AI-generated output — something the policy says is the subject of active litigation. GraalVM weighs the same IP uncertainty differently, requiring contributor accountability instead of an outright ban.
How is the ban enforced?
OpenJDK's contribution system, Skara, requires contributors to confirm compliance before a patch is accepted, attesting the submission contains no generative AI content. It's a required step in the submission process, not a voluntary disclosure.