OpenJDK's AI policy draws the line at whether a model wrote any part of a contribution

The policy sorts a tool on two tests: whether its output enters the project, and whether a large language model or similar deep-learning system produced it ^[2][11]. Reading passes the first test. Contributors may use generative AI privately to comprehend, debug and review OpenJDK code and to research changes ^[9]. The FAQ says analysis of existing code is where these tools perform best on large, established codebases ^[9]. A model may also review a draft JEP or JavaDoc, provided every submitted word is the contributor's own ^[10]. The author of a dev.to analysis of the policy wrote: "AI may read, but AI may not write anything that enters the project." ^[13]

The second test attaches to the model, so a feature's label settles nothing ^[11]. A completion engine passes or fails on what generates its suggestions. In the dev.to author's reading, classic IDE refactoring is welcome and Copilot-style completions do not belong in the jdk checkout ^[12].

The rule is one sentence: "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." ^[2] In the FAQ's example, 90 of the 100 lines would reach a reviewer exactly as the model wrote them ^[1]. The analysis found no percentage threshold and no substantial-transformation test, and puts the bar for write-path AI at one line ^[4]. Scope is the whole OpenJDK Community, so every project channel is covered, not only the JDK repository ^[6].

The policy says reliably distinguishing human-generated from AI-generated content is impossible ^[8]. I think that admission is the best engineering in the document. It does not pretend to have a detector, and it puts the claim on a named person through a checkbox in Skara ^[7]. The dev.to author wrote: "Tick it falsely and the liability trail points at you." ^[14]

The policy lists three risks: reviewer burden, safety and security, and intellectual property ^[15]. The dev.to analysis argues that reviewer burden does not explain banning AI-written bug-report prose ^[16]. By that account, the safety argument holds for any mature project, yet most such projects stopped short of an outright ban ^[16]. Intellectual property, tied to the Oracle Contributor Agreement, is the risk the analysis says best explains the breadth ^[17]. Its author says they have never contributed to OpenJDK and are not a lawyer ^[18]. In my view the read/write split fits an IP rationale. A model that only reads JDK code adds nothing to the tree whose provenance a contributor has to vouch for.

The Hacker News headline that carried the story said Oracle banned AI-generated code, and it drew 536 points and 381 comments ^[19]. The dev.to author described the thread as people arguing about a policy most of them had apparently not read ^[19]. The OpenJDK Governing Board approved it ^[1].