OpenJDK Interim Policy on Generative AI

I don't think we're approaching the limit of deterministic prompt -> source code mapping any time soon. Small variability in prompts produces medium variability in outputs. Building on previous outputs only extends the variability, where behavioral differences start appearing a few prompts down the line.

And the AI companies aren't focused on making this process any more deterministic, where repeated prompts are sampled using different seeds. I don't know if it's because the randomness makes the models explore a larger space and perform better, but it's probably intentionally done because it'd be quite easy to remove the stochasticity.

Not really though, since the result of the prompt is not deterministic. It greatly depends on the model, the version, the harness, even time of day if the provider's infrastructure is currently overloaded and is silently degrading performance. Some things also require multi-turn interactions.

Except prompts aren’t deterministic, source code is.

Is anyone using even a tiny on-device language model for spelling? For grammar, I could almost imagine it.

But this also bans "simple" AI-powered auto-complete, like Zed's Zeta2 model. This is a very conservative model that rarely tries to propose more than a few obvious lines (at least in my use cases). If a developer accepts a three-line autocomplete that introduces a bug, that's kind of on them. Honestly, about the only thing that Zeta2 is good for is reducing the risk of RSI.

To be fair, it's also their project, and I completely support their right to set whatever policies they want.

> this would exclude most spell checkers, as they often are LLM based

Who is using an LLM as a spell checker?

I think it's pretty clear how this was meant, not sure why you feel the need to split hairs here. I'm certain the intention is this:

- spell checkers: ok

- '.getC' autocompleting to '.getColor()': ok

- 'getC' autocompleting to 'getColor()' + five more lines based on preceding code and documentation: NO.

Why is it draconian? If we take Dec-2025 as the point where the models became good for real work (agreed by many), not even a year has passed since then. The world hasn't changed, and there are still many open legal questions.

> Note, this would exclude most spell checkers, as they often are LLM based

?

Like, what? What are you even talking about? Most spell checkers used by programmers are certainly not LLM based. Spell-checking has always been instant for like two decades. It's such a solved problem.

the same way they currently enforce authors own all copyright in their contributions, via the contributor agreement (OCA). in the real world, people aren’t going to intentionally sneak in LLM-authored code and potentially be legally liable.

Blockchain.

Best effort, just like in the case of existing contributor agreements that demand you to be the copyright holder.

Or like in the case of checking that free range eggs are in fact free range eggs.

Or like in the case of Steam demanding AI disclosure, to the dismay of Tim Sweeney ...

Let's hope the dismay increases over time.

Subjectively; as 100% of all laws and rules throughout history have been enforced.

As best as you can. I don't know why people keep asking this question, when the answer is obvious and exactly like all other contribution policies.

In this case, this is coming from Oracle, which holds the OpenJDK purse strings, so being found in violation is also likely to have financial consequences for the violator.

> How do you enforce this?

It's not impossible - right now there are all these low-effort PRs. If the PR is indistinguishable from a normal human-written PR, that addresses some of their concerns.

In any case, a rule or policy that can be worked around is not a reason to do away with that rule or policy.

I mean, if we only ever catch 10% of murderers, do you really think it is reasonable to remove that law from the books?

What spyware is there in the JDK? It's open-source, so you can look for yourself.

Because, as the FAQ section clearly states, the technical and management aspects are not the only ones. There are also legal issues, and until they are clarified or resolved it's best not to let code in that has the potential of causing problems later.

We're talking about one of the biggest and most critical open source projects in the world, and unless there's some immediate urgency, it's okay to wait before taking on some risk.

I should add that the potential loss here isn't big. For any fix, enhancement, or feature in the JDK, the cost of writing the code is rarely more than 10% of the total cost (which is easy to see if you compare the number of people involved in the project to the rate of code being added or changed), and the interim policy explicitly does allow the use of AI where it helps the most.

All "interim" AI contributions to OpenJDK can and will be sued to make big money off of Oracle if those court cases don't go a certain way.

This is ironic given how Oracle has bet almost everything on AI succeeding.

The interim policy you're proposing seems to have far different priors. The clearest indication of their stance is that they don't even want bug reports that have AI generate part of the text. You don't take a stand like that (imo) unless you've experienced some serious AI-related burnout.

The copyright issue is an important one. Under the current law, you don’t own copyright on the output of GenAI.

> short sighted for an interim policy

Bit of an oxymoron, no?

> just require clear and detailed disclosure of the use of said tools

Do you mean disclosure of the use of tools used "privately to help comprehend, debug, and review" contributions? Or do you mean that they should not prohibit AI-generated contributions?

If the former I wonder how useful the data would be, and if the latter, they are probably not (yet) willing to allow such contributions because of the mentioned risks: "to reviewer burden, to safety and security, and to intellectual property."

I suspect one of the principle reasons for the blanket decline is specifically that AI generated PRs are already responsible for a substantial uptick in the amount of work required to be done by maintainers. Engaging in discussions about those PRs may be more fulfilling and useful for the developer but it also then increases that work yet again manifold, so that would likely be highly counter-productive.

What I don't understand is: if you, for example, are a heavily AI-using dev, who spots a problem in OpenJDK, and you use Claude to figure it out: ok, why can't you then write the solution and PR yourself? Write your own code to replicate the functionality that Claude did, in your own style. Have Claude explain why this fixes the issue (it probably already did) and test it. If it works, write your own explanation and submit it as a PR.

I've done this a handful of times for smaller projects, in languages I'm unfamiliar with. Nobody complained because I didn't just copy the shit out of Claude, paste, copy the explanation, paste, and make a PR. I used Claude to increase my understanding, if even a bit and in a necessarily incomplete way, and did it myself.

Why would companies accept AI generated code, it they can generate their own (and review the prompt)?

It's like predicting that when compilers become more popular, accepting binary contributions will become the default.

At this point, I wouldn't be too surprised if LLMs just get better at "write understandable, maintainable code" than most developers are.

For now, LLMs are still bad at it, but they're already at "competitive with humans" tier of bad. I expect them to get better.

I don't know the timeline, but I generally agree.

I think history agrees too, i.e. machine code > assembly language > high-level programming language > prompts.

Yes, I'm sure that insecure slop projects like Artifactory will ban human contributions.