Java, the language running inside billions of devices and most of the world's enterprise back-ends, will not accept a line of code written by AI. That is now the formal position of OpenJDK, the open-source project where Java is actually built. And the company that stewards it — Oracle — has a chief technology officer who cannot stop talking about how AI writes Oracle's own software.

At first glance that looks like a clean case of do-as-I-say. It is worth slowing down, because the real story is more useful than the hypocrisy headline.

What the policy actually says

The rule is the OpenJDK Interim Policy on Generative AI, approved by the OpenJDK Governing Board. Oracle, as the project's corporate sponsor, says it is drafting a fuller policy to propose to the Board in due course; until then, this interim one holds. It was published earlier this year, in April 2026, and it is blunt:

"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."

"Content" is defined broadly — source code, text and images, across Git repositories, GitHub pull requests, email, wiki pages and issue trackers. And "in part" means what it says. The policy's FAQ spells out that generating a hundred lines with an AI tool and hand-editing ten of them still leaves you with a contribution you may not submit. There is no 10%-human loophole.

What the policy does not ban is private use. Contributors may still use AI tools to help them read, debug and understand OpenJDK code, and to do research — they simply cannot contribute the output. The line is drawn at what enters the shared codebase, not at what a developer does at their own desk.

Three reasons, and none of them is "AI is bad"

The policy gives three grounds, and they are worth separating because they do not all generalise.

Reviewer burden. AI tools make it trivial to produce large volumes of plausible-looking code and plausible-looking tests that are nonetheless wrong, or correct but badly designed and hard to maintain. Reviewing that flood drains the limited time of human reviewers. This is the practical objection, and several other open-source projects have reached the same conclusion.

Safety and security. The JDK sits under mission-critical systems in businesses and governments. Plausible-but-wrong code is a worse failure mode there than almost anywhere else.

Intellectual property. This is the one that bites hardest, and it is specific to how OpenJDK takes contributions. The Oracle Contributor Agreement requires that a contributor actually own the IP rights in what they submit, and grant those rights to Oracle without restriction. Most generative models are trained on copyrighted and licensed material, their output can reproduce it, and whether the human prompting the tool even holds IP rights in the result is — in the policy's own words — "the subject of active litigation." You cannot grant rights you may not have.

The contradiction is real

Here is where it gets awkward for Oracle. GraalVM, another Oracle-stewarded project, runs the opposite policy: its contributors may use AI coding assistants — tools that "draft, transform, explain, review, or summarize code, tests, documentation, or commit text." Same corporate parent, opposite rule.

And then there is Larry Ellison. At Oracle AI World in 2025, Oracle's co-founder and CTO said: "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." This is a company spending on the scale of tens of billions of dollars to build the datacentres that AI-written software is supposed to run on. Its public posture is that AI writing code is the future it is buying.

So one arm of Oracle bans the thing another arm of Oracle celebrates.

Why it mostly isn't hypocrisy

The reconciliation is not hard to find, and it is the part readers should take away.

OpenJDK is a public commons. Its code is contributed by volunteers and Oracle staff alike, reviewed by a limited pool of maintainers, and governed by an IP agreement that assumes a human author who owns their work. Every one of the policy's three reasons lands hardest in exactly that setting: the reviewers are a scarce shared resource, the codebase is load-bearing for the entire Java world, and the OCA's ownership requirement simply cannot be satisfied by output of uncertain provenance.

Oracle's own products are a different animal. Oracle owns the code outright, controls its own review process, indemnifies its own customers, and is not asking outside volunteers to attest to IP they may not hold. The IP objection — the sharpest of the three — largely falls away when there is no contributor agreement to violate; Oracle absorbs and indemnifies whatever copyright risk remains rather than pushing it onto a volunteer.

That distinction is the signal worth keeping. The interesting question in 2026 is rarely "is AI-written code good or bad?" It is where the code is going and who is accountable for it. A proprietary product with a single owner and a wall of lawyers is one context. A shared open-source foundation, maintained by volunteers and underpinning critical infrastructure, is another. The same tool can be a reasonable bet in the first and an unreasonable risk in the second.

Where Oracle is most exposed is on tone. It is hard to spend years telling the market that AI writes your software better than your engineers do, and simultaneously tell the world's most important Java project that AI-written contributions are too risky to accept — without someone noticing that both cannot be equally true. The policy is defensible. The messaging around it is the part that will keep drawing scrutiny.

Sources: the OpenJDK Interim Policy on Generative AI (openjdk.org/legal/ai); InfoQ's reporting on the OpenJDK and GraalVM policies (June 2026); and The Register's 3 August 2026 piece quoting Ellison's Oracle AI World 2025 remarks.