JEP 540, Simple JSON API (Incubator), has advanced to Proposed to Target status for JDK 28, according to a report published by InfoQ. The enhancement would introduce a lightweight, JDK-bundled interface for parsing, navigating, and producing RFC 8259 JSON documents without requiring third-party dependencies. The proposal deliberately focuses on a narrower scope than established libraries like Jackson and Gson, targeting routine tasks such as reading configuration files, examining REST responses, or creating small JSON payloads.

The API will ship in the incubating jdk.incubator.json module, where it can undergo incompatible changes or be withdrawn based on developer input, the report notes. The design centers on the Json class and the sealed JsonValue interface, which permits six non-sealed subinterfaces representing JSON objects, arrays, strings, numbers, booleans, and null. Instances are immutable and thread-safe. Parsing a complete in-memory document with Json.parse(String) or Json.parse(char[]) returns a JsonValue, allowing developers to traverse objects and arrays by calling access methods directly on JsonValue without repeatedly casting intermediate values. Calling get(String) on a non-object, get(int) on a non-array, requesting a missing member, or using an invalid index throws JsonValueException. JSON values are created through factory methods on the corresponding interfaces, and calling toString() on a JsonValue generates compact JSON, while Json.toDisplayString(...) produces a formatted representation intended for display. For optional object members, tryGet(String) returns an Optional that is empty when the member is absent, while tryValue() returns an empty Optional for JsonNull.

The report states that the proposal excludes data binding and streaming and offers no permissive parsing mode or syntax extensions. Strictness is a defining choice: the parser provides no lenient mode, so comments, trailing commas, and other syntax extensions are rejected. It also rejects duplicate object-member names, even though RFC 8259 says names should be unique rather than making uniqueness an absolute requirement. Different parsers may otherwise retain the first value, retain the last, preserve every occurrence, or reject the document, making duplicate names an interoperability risk, according to the report. Invalid syntax and duplicate names produce an unchecked JsonParseException, which records the zero-based line and position of the detected error, though its public API doesn't expose a structured JSON path.

The deliberate limitations reflect the report's analysis that JEP 540 concentrates on an immutable, in-memory value hierarchy and leaves object mapping, streaming, schema validation, and advanced customization to the existing JSON ecosystem. Construction ergonomics represent one likely area for feedback during incubation, since the explicit factories make each value's JSON type clear but also add ceremony because ordinary Java strings, numbers, and booleans must be wrapped before being placed in an object or array. The sealed value hierarchy works naturally with pattern matching, allowing developers to handle a producer that emits an identifier as either a JSON number or a string with a type-pattern switch. Conversion methods follow the as... naming convention: asInt() and asLong() require an exact integral value within the destination type's range, while asDouble() converts a number to a finite double but may round or lose precision.

If JEP 540 becomes Targeted and is delivered, class-path applications will need to resolve the incubator module explicitly with --add-modules jdk.incubator.json, the report notes. The incubation period will allow the OpenJDK community to evaluate the navigation model, exception semantics, numeric conversions, and construction ergonomics before the API advances further. JEP 198, Light-Weight JSON API, is a broader proposal created in 2014 that was never delivered, making this narrower approach the first JSON capability natively bundled with the JDK. The trade-off between minimalism and developer convenience will likely determine whether the standard library gains its first JSON tool or whether teams continue relying on battle-tested third-party alternatives. Organizations accustomed to Jackson's rich feature set may find the incubator API too constrained for complex workflows, while teams seeking dependency-free deployments could embrace the native option despite its ceremonial construction syntax.