OpenJDK & the JEP process — how Java evolves

Overview

Java's evolution is unusually legible: nearly everything happens in the open, in the OpenJDK project, through a documented pipeline of JEPs (JDK Enhancement Proposals) shipped on a fixed six-month cadence. Understanding the machinery — projects like Amber and Loom, the JEP lifecycle, what "preview" actually promises — is what lets you read a release note and know whether a feature is safe to adopt, worth experimenting with, or years away.

Key points

• OpenJDK is the open-source project where the JDK is built: source, mailing lists, and governance are public; Oracle leads but committers span many vendors (Red Hat, SAP, Amazon, Microsoft, BellSoft…).
• Groups and Projects: Groups are standing bodies (HotSpot, Core Libraries, Security); Projects are feature efforts with their own repos — Amber (language ergonomics: records, patterns), Loom (virtual threads, structured concurrency), Panama (native interop: FFM API, Vector API), Valhalla (value types), Leyden (startup/warmup, AOT caching).
• Roles: contributor → committer (can push) → reviewer (can approve); earned by sustained contribution. Work is discussed on mailing lists first — patches without prior list discussion are frowned upon; the lists are the real decision record.
• JEP: the unit of substantial change — a design document with motivation, spec-level description, alternatives, and risks. Small fixes don't need one; anything user-visible does.
• JEP lifecycle: draft → candidate (accepted as a good idea) → targeted to a specific release → integrated into mainline → completed when it ships. A JEP can be retargeted or dropped up until the release's feature-freeze (ramp-down).
• Stability levels: preview (complete, spec-quality, but feedback-gated — needs --enable-preview, may change between releases, compiled artifacts tied to that exact release), incubator (APIs in jdk.incubator.* modules, may change radically), experimental (VM features behind -XX:+UnlockExperimentalVMOptions, no promises). Only a final, non-preview feature carries the platform's compatibility guarantee.
• Six-month cadence: a new feature release every March and September; features ship when ready, missing the train just means catching the next one. LTS is a vendor concept, not an OpenJDK one — vendors choose which releases get extended support (8, 11, 17, 21, 25 by convention).
• JCP & JSRs vs JEPs: the Java Community Process ratifies specifications (JSRs) — today mostly the umbrella Java SE platform spec and its TCK per release — while JEPs drive individual features. JSR = spec-level standardisation; JEP = feature-level engineering.

The JEP lifecycle at a glance:

stateDiagram-v2
    state "Draft" as Draft
    state "Candidate" as Candidate
    state "Targeted" as Targeted
    state "Integrated" as Integrated
    state "Completed" as Completed
    [*] --> Draft
    Draft --> Candidate: accepted as a good idea
    Candidate --> Targeted: targeted to a specific release
    Targeted --> Integrated: integrated into mainline
    Integrated --> Completed: ships with the release
    Targeted --> Targeted: retargeted to another release (until ramp-down)
    Targeted --> Candidate: dropped (until ramp-down)
    Completed --> [*]

Details

The preview arc — pattern matching as the worked example

Preview lets a finished design soak across multiple releases before it is frozen. Pattern matching shipped as a multi-release arc: instanceof patterns previewed in 14–15 and finalised in 16; switch patterns previewed across 17–20 and finalised in 21 alongside record patterns (previewed 19–20). Each preview round incorporated real user feedback — sealed-type exhaustiveness handling and null handling in switch changed between rounds. The lesson: previews genuinely change; never ship production code on --enable-preview, but do try previews and report back — that feedback is the point.

Reading the process from outside

• A feature's JEP number is its stable identity — release notes, mailing-list threads, and conference talks all cite it (e.g. JEP 444 = virtual threads final in 21).
• The ramp-down phases (RDP1/RDP2) after fork from mainline mean the feature list for a release is effectively known ~3 months before GA.
• Vendor distributions (Temurin, Corretto, Liberica, Zulu, Oracle JDK) all build from the same OpenJDK source; they differ in support windows, packaging, and occasionally backports — see JVM implementations.

Following along

Related

• Deep dive Java — the language features this process delivered: records, sealed types, virtual threads.
• JVM implementations — how one OpenJDK source tree becomes many vendor distributions and LTS offerings.
• JDK & tools — the toolchain that ships with each release, itself evolved through JEPs (jshell, jpackage, jwebserver).
• How Go evolves and How Rust evolves — the counterpart governance notes: one company's team, and a federation of teams with RFCs and feature gates.