OpenJDK Targets JEP 540 for JDK 28, Giving Java a Built-In JSON API for the First Time

Overview

JEP 540, a proposal to add a built-in JSON API to the Java Development Kit, has reached “Targeted” status for JDK 28, according to the JEP’s official page on openjdk.org. The proposal would let developers parse, navigate, and generate JSON documents “without an external library,” as the JEP puts it, ending Java’s decade-plus reliance on third-party libraries such as Jackson and Gson for a task built into languages like Python and Go.

The JDK 28 project page lists JEP 540 among the JEPs “targeted to JDK 28, so far,” alongside JEP 401 (Value Objects Preview), JEP 535 (Shenandoah GC: Generational Mode by Default), and JEP 539 (Strict Field Initialization in the JVM Preview). By contrast, JEP 541, a separate proposal to deprecate the macOS/x64 port, remains in the earlier “proposed to target” review stage, with that review window closing August 21, 2026, per the same page. InfoQ reported on August 17, 2026, that JEP 540 had “moved from Candidate to Proposed to Target status for JDK 28” — the step that immediately precedes formal targeting.

What We Know

• The proposal, authored by Naoto Sato, Paul Sandoz, Justin Lu, and Stuart Marks, aims to “add a compact, JDK-provided API for parsing, navigating, and generating RFC 8259 JSON documents without an external dependency,” according to the JEP text. Naoto Sato is listed as the JEP’s owner, with Alex Buckley as reviewer and Paul Sandoz as endorser.
• The API will ship inside the incubating jdk.incubator.json module, meaning it is disabled by default and must be explicitly enabled with the command-line option --add-modules jdk.incubator.json, per the JEP.
• Its design is deliberately narrower than established libraries. As InfoQ describes it, the API “excludes data binding and streaming and offers no permissive parsing mode or syntax extensions,” focusing instead on tasks such as reading a configuration file or inspecting a REST response.
• The API centers on a sealed JsonValue interface. The JEP states that “the JsonValue interface thus has six corresponding sub-interfaces: JsonString, JsonNumber, JsonBoolean, JsonNull, JsonObject, and JsonArray,” and that the interface “is sealed, which guarantees that any JsonValue instance is always one of this fixed set of subtypes.” According to InfoQ, instances of these types “are immutable and thread-safe.”
• Parsing is strict by design. The JEP specifies that “syntax extensions such as trailing commas and comments are not supported” and that “documents must not have objects with duplicate member names” — a policy RFC 8259 permits but does not require, since the RFC only says names “SHOULD be unique.” Violations throw an unchecked JsonParseException that, per the JEP’s example, reports the exact location of the error, such as: The duplicate member name: "providers" was already parsed. Path: "{". Location: line 2, position 4.
• JEP 540 supersedes an earlier attempt. The JEP itself notes it “supersedes JEP 198, Light-Weight JSON API, which was written in 2014.” InfoQ adds that JEP 198 was “a broader proposal created in 2014 that was never delivered.”
• The current proposal explicitly narrows that earlier ambition: JEP 540’s stated non-goal is that “it is not a goal to create an API that supplants established external JSON libraries” like Jackson, Gson, and Jakarta JSON Processing and Binding, which the JEP names as part of the existing Java JSON ecosystem.

What We Don’t Know

• Because the API remains in the jdk.incubator.json incubator module, its design can still change or the feature can still be dropped before a stable release. The JEP states that during incubation, the team “will gather more information about use cases involving generating and transforming JSON documents, in order to evolve these areas of the API.”
• Neither openjdk.org page reviewed lists a firm general-availability date for JDK 28. Oracle recently delayed the first release candidate for JDK 27 by two weeks, and JDK 28 is the feature release that follows JDK 27 on Java’s twice-yearly cadence, but no specific JDK 28 ship date appears in the sources reviewed for this article.

Analysis

The JEP frames the motivation in practical terms rather than purely architectural ones: JSON handling in Java currently requires “installing an external library,” while “the Python or Go code to accomplish such tasks is simple.” The JEP also points to a secondary benefit — since “the JDK cannot have external dependencies,” a standard JSON API would let the JDK itself use JSON internally, for example in configuration files that today rely on Java’s older, flatter Properties file format.

The emphasis on strictness — rejecting duplicate keys, comments, and trailing commas — reflects a deliberate trade-off toward interoperability over convenience. The JEP argues that objects with duplicate member names are “fundamentally ambiguous” across different JSON libraries, and cites RFC 9413, “Maintaining Robust Protocols,” in support of treating them as errors outright rather than silently picking a winner.