Oracle Wrote Two AI-Generated Code Policies. They Contradict Each Other.

Oracle's OpenJDK, the reference implementation of Java, and Oracle Labs' GraalVM sit under the same parent company, require contributors to sign the same legal agreement, and reached opposite conclusions on the same question within weeks of each other. One project's AI-generated code policy bans it outright. The other welcomes it, with conditions attached. Neither answer is obviously wrong, which is exactly why the split is worth studying if you are drafting a policy of your own.

Two projects, one owner, opposite answers

In April 2026, the OpenJDK Governing Board approved an interim policy stating that contributions "must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems" (openjdk.org/legal/ai). The ban covers source code, commit messages, pull request descriptions, wiki pages, and issue trackers, essentially anything that becomes part of the permanent project record.

Five days later, GraalVM, an Oracle Labs project that sits outside the OpenJDK Governing Board's authority, published a "Coding Assistants" policy that runs the other direction: contributors "may use AI coding assistants and similar tools when preparing contributions," provided they take full responsibility for what ships (InfoQ). Both projects require the same Oracle Contributor Agreement and the same grant of unrestricted intellectual-property rights to Oracle. The only difference is judgment about risk.

What OpenJDK's AI policy actually bans

The OpenJDK AI policy is stricter than most people assume when they hear "AI code is banned." The policy's own FAQ addresses the obvious workaround directly: generate 100 lines with an LLM, hand-edit ten of them, and you still cannot submit the result, because the contribution "would still include, in part, AI-generated code." Partial credit does not exist here.

What survives is private use. Contributors can run an assistant to understand unfamiliar code, debug a failure, or review a draft document, as long as the tool's output never becomes the submitted content. Editor features like spell-check, grammar-check, and refactoring are also fine, so long as they are not themselves built on a large language model.

OpenJDK gives three reasons, worth separating because most teams collapse them into one vague worry about "AI code quality." First is reviewer burden: a contributor can generate plausible-looking code faster than any reviewer can verify it, which inverts the usual cost balance of open source. Second is safety, since the JDK underpins production systems where a subtly wrong implementation is worse than an obviously wrong one. Third, and the one most teams skip entirely, is intellectual property: the Oracle Contributor Agreement requires contributors to own the rights they hand over, and whether anyone owns the output of a model trained on other people's code is still being litigated, not settled.

Why GraalVM chose disclosure over prohibition

GraalVM's policy treats the same three risks as manageable through accountability rather than avoidance. Its guidance is explicitly modeled on the Linux kernel's own AI coding-assistants policy, adapted to be looser in one specific way: Linux asks for an "Assisted-by" tag on AI-touched commits, while GraalVM makes that disclosure of AI-generated code optional, only "encouraged when it helps reviewers understand how a change was produced."

The load-bearing clause in GraalVM's policy is this: "If a contributor cannot explain, defend, or maintain an AI-assisted change, the contribution may be rejected." That single sentence does the work OpenJDK's ban does through prohibition. It does not ask whether a tool touched the code. It asks whether a human can stand behind it.

The choice both policies are actually making

Strip away the Java specifics and each project is answering the same underlying question differently: is the real ai code review risk the code itself, or the human's understanding of it? OpenJDK bets that plausible-looking, subtly wrong code will slip past reviewers faster than a "did you actually understand this" checkbox can catch it, so it removes the option entirely. GraalVM bets that a contributor who has to defend a change line by line will filter out the worst failure modes on their own, so it keeps the option and shifts the cost onto accountability.

Neither project treats this as settled. OpenJDK explicitly calls its own policy interim while Oracle drafts something more permanent. GraalVM's guidance is newer still, published as a living document rather than a governance ruling.

What this means for your own AI-generated code policy

Most engineering teams do not have an AI-generated code policy at all. They have an unspoken assumption that whatever a developer's editor autocompletes is fine, and no clear line for what happens once that editor is running a full coding agent instead of an autocomplete model. Oracle's split gives a template for the actual decision, not a specific rule to copy.

Three questions, drawn directly from the reasoning above, are worth answering before writing an AI coding assistant policy for your own repository or team:

Who reviews the output, and how much of their time can a flood of AI-generated pull requests realistically consume before review quality drops. Who owns what ships, given that "an AI wrote it" is not currently a settled legal defense for either copyright or liability. And can the person submitting a change explain and defend every part of it without deferring to the tool that produced it.

If the honest answer to that third question is no, GraalVM's own contributor-responsibility rule applies whether or not your team writes it down: "use of AI assistance does not create any presumption that a change is correct, review-ready, or exempt from normal scrutiny." That line holds regardless of which side of Oracle's split your team lands on.

---

Sources: OpenJDK Interim Policy on Generative AI, published April 9, 2026. Karsten Silz, "Oracle's OpenJDK Bans Generative AI Contributions While Oracle's GraalVM Allows Them", InfoQ, June 12, 2026.