Serguey Asael Shinder: A JSON API in the JDK: what JEP 540 chooses to leave out is the point
JSON is the default wire format for machine-to-machine communication, and yet, after all these years, the Java Platform still has no standard way to parse it — every project reaches for an external library. JEP 540, "Simple JSON API (Incubator)," targeted for JDK 28, proposes to change that. This column is about what the JEP's own goals say about the design philosophy; the specification is in the JEP, and the API is incubating, so it can change.
What it is. The JEP proposes "a simple, standard API for parsing and generating JSON documents so that doing so does not require an external library," able to process RFC 8259-compliant JSON "with low ceremony." It explicitly supersedes the long-dormant JEP 198 ("Light-Weight JSON API") from 2014, saying circumstances have changed and it takes a different approach. Being an incubator module, it ships for feedback and is not yet a permanent part of the platform.
The interesting part is the non-goals. A JSON library could do a great deal; this one deliberately does not. The JEP's goals say to "keep the API small, simple, and easy to learn" and to "provide only those data types and operations required for strict conformance to RFC 8259." And it names what it avoids: multiple parsing configurations, syntax extensions, data binding, and streaming. That is a pointed set of exclusions. No data binding means it will not, by itself, map JSON onto your classes the way Jackson or Gson do. No streaming means it is not aiming at multi-gigabyte documents. No syntax extensions means no trailing commas or comments — strict RFC 8259 only.
Why those choices make sense. The JEP offers a line worth sitting with: because JSON documents have no schema, "code that navigates and extracts data from JSON documents with a known structure" serves as "a de facto schema and should be readable as such." In other words, the API's job is to make the reading code legible, so the code that pulls fields out doubles as documentation of the expected shape. That is a different ambition from a full-featured library. The platform is not trying to replace Jackson for complex binding; it is trying to make the common, simple cases — parse this, read these few fields, generate that — need no dependency at all, and stay readable. For a column, the takeaway is that the restraint is the feature: a JDK JSON API that tried to do everything would just be another library to choose against, whereas a small strict one covers the cases where pulling in a dependency was never worth it.
Source: OpenJDK, "JEP 540: Simple JSON API (Incubator)" — https://openjdk.org/jeps/540