The OpenJDK project has published JEP 540, a proposal for a standard API to parse and generate JSON documents directly within the JDK. Published on 2026-07-23 GMT, the proposal is designated as an incubating API under JEP 11 — the established mechanism for introducing new JDK features that are not yet finalized. (OpenJDK)

JEP 540 supersedes JEP 198, titled "Light-Weight JSON API," which was originally written in 2014. That earlier proposal never made it into the JDK, leaving Java developers reliant on external libraries for JSON processing. The new proposal picks up the thread more than a decade later with a narrower scope and a sharper set of constraints.

JSON — short for JavaScript Object Notation — is a lightweight text format for storing and transporting structured data. It has become the dominant format for data exchange between servers, APIs, and configuration files across virtually every programming language.

A stated goal of the proposal is to make the JDK itself capable of parsing and generating JSON documents. This is a distinct framing from building a comprehensive JSON framework. The API deliberately avoids features such as multiple parsing configurations, syntax extensions, data binding (the automatic conversion between JSON and Java objects), and streaming (processing large documents incrementally). What remains is intended to be a minimal, conformant interface for reading and producing JSON.

Conformance is a key design constraint. The API targets strict adherence to RFC 8259, the IETF standard that defines the JSON interchange format. By binding to a single specification rather than offering configurable parsing modes, the proposal sidesteps the compatibility and interoperability questions that arise when libraries extend or relax JSON syntax.

The JEP explicitly names Jackson, Gson, Jakarta JSON Processing, Jakarta JSON Binding, and Fastjson 2 as established JSON libraries in the Java ecosystem. It is a stated non-goal to create an API that supplants them. This is an unusually clear delineation of scope. The JDK is not attempting to replace the rich feature sets that production applications depend on, such as object mapping, streaming parsers, or pluggable serialization strategies. Instead, the proposal positions a built-in API as a baseline capability for cases where an external dependency is unnecessary or undesirable.

The decision to incubate the API under JEP 11 rather than deliver it as a stable feature in a specific release signals that the design is still open to revision based on community feedback. Incubator modules ship with a jdk.incubator package prefix, which prevents downstream code from treating the API as a stable contract before the design is finalized. For developers who have been through this cycle before with incubating JDK features, the implication is straightforward: the API may change before it exits incubation, and production use carries that risk.

The broader context here is that JSON has been a de facto interchange format for over fifteen years, and the JDK has never shipped a native API for it. Java developers have built around this gap with varying degrees of formality. Some teams standardize on Jackson for its breadth; others reach for Gson's simplicity; enterprise environments often adopt Jakarta EE's standardized binding and processing APIs. The absence of a JDK-native option has been a minor but persistent friction point, particularly for tooling, build scripts, and library code that would prefer to avoid pulling in a third-party dependency for a straightforward parse-or-serialize task.

Worth flagging is the contrast with how the JDK has handled other widely used formats. The platform has long included native support for XML through the JAXP family of APIs, and properties handling has been built in since the earliest days. JSON's omission from the standard library became more conspicuous as the format displaced XML in most new API and configuration scenarios. JEP 540 addresses that gap, though its intentionally limited scope means the established libraries are not at risk of displacement for the use cases they were designed to serve.

The inclusion of RFC 8259 conformance as a hard target is a practical choice. It means the API will parse what the spec defines and reject what it prohibits, without offering escape hatches for malformed or extended JSON variants. Developers currently working with libraries that offer lenient parsing modes, or that support non-standard extensions like comments or trailing commas, will not find equivalent behavior in this API. That constraint is consistent with the proposal's stated simplicity goal, but it does set a boundary on where the built-in API is useful.

For teams that need only read a JSON configuration file, produce a JSON response in a lightweight service, or handle JSON in a context where adding a dependency is costly, the proposed API could reduce friction. For anything more demanding, the external libraries the JEP itself cites remain the appropriate tools.

The incubation status means the design is not yet frozen. Developers and library authors who care about the shape of this API have a window to provide feedback through the standard OpenJDK channels before it stabilizes.