Towards a JSON API for the JDK

[Paul Sandoz]

JEP 198 will likely be withdrawn and a new JEP will be drafted aligned with the document sent in this email thread.

It’s a not a goal to solve the dependency problem (a very hard problem!) even in a narrow sense.

A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0, and potentially so with further out features. This has a number of advantages:

1. It should enable us to devise a simpler API that naturally gains more power as it is used in combination with those features;
2. It provides feedback to those features and perhaps the other way around too; and
3. It provides a template for others to copy in their own libraries.

Paul.

> On May 20, 2025, at 12:53 AM, Swaranga Sarma <sarma.swaranga at gmail.com> wrote:
> 
> Hello, I am not a language or a library developer by any means but I wanted to offer my perspective as a prospective user of such an API. 
> 
> I am sure this was considered but feel compelled to raise it regardless - instead of the low level tree API (and baking whatever design choice is made forever into the JDK), was a higher level data binding API considered while keeping any low-level tree implementation private to the JDK? Basically a way to take a Json document (String/Reader/...) and deserialize it into an instance of a user-defined Record (and vice versa). From my perspective, this would be a more useful addition for the simpler and most common cases and if there are more complex requirements around flexibility/performance then there are lots of 3rd party options available in Java. I do not have data to back my hunch that this will be more valuable but I am offering my real production use-case where I would find it useful: 
> 
> I have a bunch of rest APIs for which my callers want me to vend a Java client that has the Java POJO classes for the request and response shapes; they don't want to write it by hand which is a reasonable ask. I usually create a Java library that uses the standard Java Http client under the hood to make the calls and serialize and deserialize the DTOs using Jackson. The problem is that as soon as I add Jackson to the client library's dependencies, it is no longer a zero-runtime dependency library and the callers have to deal with multiple versions, version incompatibility etc (in case they also use Jackson in the client app). With a Json api with support for data binding in the standard library, I could vend a very thin zero additional dependencies Java client to my callers.
> 
> This is not quite what JEP 198 is stating as its goals but I am also not sure if this discussion is towards an implementation for that JEP.
> 
> Thank you
> Swaranga