Oracle Banned AI-Generated Code From OpenJDK. Its Own GraalVM Team Didn't Get the Memo.

Picture two people at Oracle, one floor apart. One of them just spent months drafting a legal memo that bans AI-generated code from Java’s core repository, full stop, no partial credit. The other is two doors down, merging a pull request that an AI wrote most of, into a different Oracle project, in the same month.

That’s not a hypothetical. That’s April 2026, and it actually happened.

I write a lot about Xcode’s AI agent because I use it every day — it’s in my last three months of commits. So when I saw one of the biggest open source projects on Earth ban the thing I do for a living, and then watched its sister project wave it through, I wanted to know what the Swift compiler’s own repo actually says about this. Short answer: nothing. That silence is more interesting than either Oracle policy.

What OpenJDK actually banned

In April 2026, OpenJDK’s Governing Board published an interim policy on generative AI that’s about as blunt as legal writing gets:

“Contributions must not include content generated, in part or in full, by large language models, diffusion models, or similar deep-learning systems.”

Not “disclose it.” Not “review it carefully.” Banned. Partial AI assistance counts the same as a fully AI-written patch — there’s no tier where “I used autocomplete for one function” gets a pass. Contributors will eventually have to certify compliance through Skara, OpenJDK’s own review tooling, which means this isn’t a suggestion sitting in a CONTRIBUTING.md nobody reads. It’s enforced at the gate.

The policy gives three reasons, and they’re worth sitting with because none of them are “we don’t like robots”:

Reviewer burden. AI output is plausible-sounding and often wrong in ways that take longer to catch than to write.
Security. The JDK runs a meaningful chunk of the world’s backend infrastructure. A subtly wrong patch here isn’t a UI bug.
IP uncertainty. Nobody has a clean legal answer yet for what a model trained on GPL and Apache code actually owes anyone when it reproduces a pattern.

And then there’s this line, which I had to read twice: the policy itself admits that “reliably distinguishing human-generated content from AI-generated content is impossible,” and asks reviewers to watch for tells anyway. Oracle wrote a rule it knows it can’t verify.

Meanwhile, one floor over

GraalVM — also Oracle, also using the same Oracle Contributor Agreement, just governed outside the OpenJDK umbrella — adopted the opposite policy the same month. Contributors are explicitly allowed to “use AI coding assistants and similar tools when preparing contributions.” The safeguard isn’t a ban, it’s accountability: “If a contributor cannot explain, defend, or maintain an AI-assisted change, the contribution may be rejected.”

Read that again. One Oracle project says the tool itself is the problem. The other says the tool is fine, the problem is contributors who don’t understand their own patches. Same company, same legal department presumably signed off on both, completely incompatible theories of what’s actually risky.

I don’t think this is Oracle being incoherent for no reason — I think it’s what happens when a big organization tries to write a policy for a moving target and two different teams land in two different, both defensible, places. Which is exactly why I went looking for where Swift landed.

So what does the Swift compiler’s repo say?

I checked. As of this writing, nothing. There’s no AI.md, no clause in swiftlang/swift’s CONTRIBUTING guide, no public statement from the Swift Core Team staking out a position the way OpenJDK or GraalVM did.

That’s not necessarily bad — it might just mean nobody’s forced the question yet at the scale OpenJDK hit. But it’s worth being honest about what fills that gap right now: the Swift Evolution process itself. Every proposal that touches the language goes through public review and a Core Team decision before it lands, which is a slower, heavier checkpoint than most PRs get in any language’s compiler repo. That process was designed for a world of human proposal authors arguing on a forum, not for the volume an AI agent could theoretically generate. It’s held so far. I don’t think anyone’s tested whether it holds at OpenJDK’s scale of concern.

LLVM — which the Swift compiler is built on — has actually had this argument in the open, and it’s the most useful of the three positions because nobody’s fully won it yet. The existing rule is closer to GraalVM’s: “contributors are considered responsible for their contributions… to verify its correctness and to understand it so that they can answer questions during code review.” But by last September, one of the maintainers was already drafting something stricter, framed around “extractive contributions” — patches that cost the project more reviewer time than they’re worth, regardless of how they were written. That reframing is smarter than a blanket ban, because it doesn’t actually care whether a human or a model wrote the bad patch. It cares whether reviewing it was worth it. A maintainer arguing the other side put it well: an outright ban risks filtering out the exact new contributors a language project needs, not just the low-effort ones.

Why this isn’t just Java’s problem

Here’s the thing that makes this land for Swift developers specifically, not just as interesting Java gossip: Apple wired Claude and Codex directly into Xcode via MCP, and I’ve written about how much smoother that agentic workflow got as the tooling matured. That’s fantastic for shipping your own app. It’s a genuinely open question for a compiler or a widely-used Swift package that takes outside contributions.

If Apple’s own AI-assisted workflow becomes the default way Swift developers write code — and for a lot of us, myself very much included, it already has — then every open source Swift project downstream is going to run into the same question OpenJDK just answered one way and GraalVM answered the opposite way. Right now, the honest answer for most Swift package maintainers is: there is no answer. Nobody’s written it down.

That’s the same structural strain I covered when curl killed its bug bounty and Ghostty banned AI contributors outright — this isn’t a new crisis, it’s the same one, just showing up with an actual legal document attached instead of a maintainer’s frustrated blog post. And the underlying data backs up why maintainers are twitchy: a study I wrote about back in April found PR volume up 20% and review quality down 23% across a sample of over a thousand developers — which is precisely the “reviewer burden” OpenJDK’s policy names as reason number one.

What I’d actually do with this

If you maintain a Swift package that takes outside PRs, you don’t need to copy OpenJDK’s language verbatim. But you do need a stated position, because “we’ll figure it out case by case” is not a policy, it’s a vacuum that fills itself with whichever contributor pushes hardest. GraalVM’s framing is the one I’d start from for most Swift projects: not “was this AI-assisted,” but “can the person submitting this explain and defend every line of it.” That question filters the actual risk — a contributor who can’t answer it is a review-burden problem whether a model wrote the code or they copy-pasted it from a five-year-old Stack Overflow answer at 2 AM.

If you’re the one submitting PRs with an agent’s help, the LLVM framing is the useful discipline to steal even without a written rule forcing it on you: read every line before you send it, because “extractive” is a real thing reviewers can smell, and a maintainer who gets burned once starts treating every contribution from you with the same suspicion OpenJDK now writes into policy for everyone.

I use an AI agent inside Xcode every single day and I’m not going to pretend otherwise on this blog. But there’s a real difference between “I used it to write my own app, which I alone am responsible for,” and “I used it to write a patch someone else now has to review, understand, and maintain.” OpenJDK picked a blunt answer to that second case. GraalVM picked a permissive one. Swift, as far as I can tell, hasn’t picked yet — and given how much AI-assisted Swift is about to start flowing through open source packages, that’s a gap somebody’s going to have to close before it closes itself the hard way.

For more on where the Xcode side of this tooling actually stands today, our vibe coding course covers the workflow this whole debate is actually about — using the tools well enough that “can you defend this line” is never a question you’d fail.