OpenJDK Banned AI Contributions. GraalVM Didn’t. Both Are Oracle.

In early April 2026, the OpenJDK Governing Board published an interim policy banning all AI-generated contributions to the project — source code, text, images, email threads in the project’s bug tracker, entries in the JBS issue system. Two weeks later, GraalVM, an Oracle Labs project that runs on the same JVM infrastructure and requires the identical Oracle Contributor Agreement, published its own AI policy permitting contributors to use any AI coding assistant they want. Larry Ellison had already told Oracle AI World 2025 that AI writes Oracle’s own code. Three different positions from one company, and nobody at Oracle has explained how that’s possible, or how long the contradiction can hold.

What the Ban Actually Covers

The OpenJDK policy is not a guideline or a recommendation. The exact language from the Governing Board: “Contributions must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems.” The scope is comprehensive — not just pull requests, but email threads in OpenJDK’s mailing lists, entries in the JBS issue tracker, wiki pages, and repository documentation. InfoQ’s coverage of the policy clarifies what the rule means for partially AI-generated work: editing 10 of 100 AI-generated lines still constitutes a violation. There is no threshold below which AI assistance becomes acceptable. The tool is the problem, not the quality of the output.

The compliance mechanism is concrete. A checkbox is being added to Skara, OpenJDK’s pull request system, requiring contributors to certify their submissions are AI-free before a PR can be opened. This isn’t guidance buried in a README — it is going into the tooling itself, in front of every contributor at the moment of submission. The project is treating AI compliance the way it treats copyright assignment: as a gateable step, not a community norm.

The detection approach reveals something worth sitting with. JVM Weekly’s coverage of the policy reports that reviewers are told: “if something in a pull request seems uncannily cheerful or meticulous then you could be looking at AI-generated content” — and that emoji use is flagged as one signal. Read that carefully. OpenJDK’s maintainers are being asked to pattern-match for AI-generated submissions they cannot technically distinguish from human-written ones. The detection problem is being solved by taste and intuition, which are exactly the kinds of judgments that will fail consistently and differently across different maintainers. The policy says no AI. The enforcement says: we’re hoping someone notices.

OpenJDK underpins mission-critical systems on a scale that makes the caution understandable. Java forms the backbone of enterprise banking, healthcare, and logistics infrastructure globally, and is the reference implementation for a language that has been in production for 30 years. A garbage collector bug or a subtle race condition in the JVM core is not an academic concern — it is a CVE affecting every Java shop on the planet. A Java vulnerability at that layer is not a browser bug you patch and move on from; it propagates through supply chains that took decades to build. From that vantage point, “plausible-looking but incorrect code” is a real operational risk, not a hypothetical. The ban has a defensible logic. What it lacks is consistency.

Two Oracle Projects, Opposite Conclusions

GraalVM’s policy, published to the project’s GitHub repository in mid-April 2026 and updated with a full agents document in early June, says this: “GraalVM contributors may use AI coding assistants and similar tools when preparing contributions.” Attribution of AI assistance is encouraged but explicitly optional. No mandatory “Assisted-by” tag, unlike the approach the Linux kernel project adopted when it addressed the same question. The CODING_ASSISTANTS.md document is direct: “explicit attribution to a specific model or tool is optional.”

The accountability model is not lighter — it is different. GraalVM contributors must “review and understand the submitted code, tests, documentation, and commit messages.” If a contributor cannot explain, defend, or maintain an AI-assisted change, the contribution may be rejected. Maintainers retain authority to request clarification about provenance, design intent, and contributor understanding for any submission. The policy explicitly states that “AI assistance creates no presumption that a change is correct.”

That last line matters. GraalVM is not treating AI-generated code as automatically good. It is treating it as code — subject to the same review scrutiny, the same accountability standards, the same right of maintainers to reject anything they can’t verify. What GraalVM is saying is that the right question is not “was this written by a human?” but “does this contributor understand what they are submitting and can they defend it?” That is the question Linux asks. That is the question the industry’s most productive open-source contributors have converged on. OpenJDK chose a different answer — and the fact that it is legally possible for two Oracle-controlled projects to reach opposite conclusions proves the answer is a choice, not a constraint.

GraalVM is subject to the same OCA as OpenJDK. The IP certification problem exists for GraalVM contributors too. What GraalVM is betting is that contributor accountability is sufficient to manage that risk — that a human who certifies they understand, can defend, and take responsibility for AI-assisted code has done enough to make the OCA certification meaningful. OpenJDK is betting the opposite: that contributor certification over AI-generated content is impossible to make reliable, so the category has to be excluded entirely. Both bets have a logic. Only one of them is also the policy Oracle applies internally.

The IP Problem OpenJDK Is Actually Solving

Three reasons appear in every account of the OpenJDK ban: review burden, security for critical infrastructure, and intellectual property. The first two are in tension — AI-accelerated contribution volume is a real concern, but tighter review of AI-assisted contributions addresses both. The IP concern is where the policy becomes structurally interesting, and where the comparison with GraalVM breaks down.

The Oracle Contributor Agreement requires contributors to certify that they own the intellectual property they are contributing and have the unrestricted right to grant Oracle a license to use it. The Register’s reporting on the policy notes that courts in the US and EU have not resolved whether individuals own the copyright of AI-generated output, or whether it enters the public domain, or whether it belongs to the AI provider. Depending on the jurisdiction and the answer, a contributor submitting AI-generated code may not be able to certify OCA compliance accurately. If they certify incorrectly, Oracle’s legal exposure as project steward compounds accordingly.

This is the liability transfer the ban is accomplishing. External contributors bear the compliance risk when they certify OCA compliance. A blanket prohibition removes the problem by eliminating the class of contribution where the certification might be false. Oracle doesn’t have to adjudicate which AI-generated submissions are legally clean — it just excludes them all and lets contributors self-certify against a much simpler binary. The review burden argument and the quality argument are real, but they do not explain why the ban extends to email threads and bug tracker comments, which are not subject to OCA licensing. The IP argument does.

What Oracle Doesn’t Apply to Itself

Ellison at Oracle AI World 2025 was unambiguous: “The code that Oracle is writing, Oracle isn’t writing. 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. We don’t write the procedure. We declare our intent, but the model writes the step-by-step procedure.” Co-CEO Mike Sicilia credited the same tooling with enabling “smaller engineering teams to deliver more complete solutions…more quickly.”

Oracle’s internal AI-generated code doesn’t pass through an OCA certification. Oracle’s engineers don’t check a Skara checkbox before merging. Oracle’s reviewers handle the review burden of AI-written internal code, and if that code has an IP problem, Oracle’s lawyers handle it — internally, at Oracle’s scale, with Oracle’s legal budget. The liability that’s undefined and externalized for a Java contributor who submits AI-generated code is fully internalized and manageable for Oracle engineering.

The policy is consistent with this picture once you read it as liability management rather than quality management. Oracle isn’t saying AI-written code is too dangerous for production. It’s saying AI-written code is too legally complicated for contributors who cannot absorb the legal exposure that comes with uncertain IP certification. The ban protects OpenJDK’s legal chain of custody. The cost is that Java’s contributor base is now operating under the most restrictive AI policy of any major open-source runtime — more restrictive than Linux, more restrictive than GraalVM, more restrictive than the policy that Oracle applies to its own engineering teams.

JDK 27 is scheduled for September 2026, with Project Valhalla’s value classes as the marquee feature. Whether Java’s contributor pipeline can sustain that kind of feature velocity while banning the tooling most engineers now use daily is a question the current policy doesn’t answer. The OpenJDK Governing Board has explicitly described the ban as temporary, pending a final AI policy. What that policy will say about IP certification — and whether it will apply the same standard to Oracle’s internal contributors — will say more about Oracle’s institutional AI posture than any earnings call statement about how the models write the code now.

AI-generated editorial illustration · TemperatureZero · August 8, 2026