Towards a JSON API for the JDK

[Johannes Döbler]

Developers use JSON libraries like Fastjson, Jackson and Gson primarily 
(my claim) because they can marshal between JSON files and POJOs in one 
line of code with great performance and can easily tweak the mapping 
using annotations or adapter classes.
Being able to read/write a JSON file from/to a generic tree of 
JsonValues might have use-cases, but manually implementing data-binding 
based one tree traversal w/wo pattern matching will produce bloated and 
fragile code (my claim).
So my question is if there are plans to address data-binding in the 
future and how it would relate to the envisioned core API.
Thanks
Johannes


> # Towards a JSON API for the JDK
>
> One of the most common requests for the JDK is an API for parsing and generating
> JSON. While JSON originated as a text-based serialization format for JSON
> objects ("JSON" stands for "JavaScript Object Notation"), because of its simple
> and flexible syntax, it eventually found use outside the JavaScript ecosystem as
> a general data interchange format, such as framework configuration files and web
> service requests/response formats.
>
> While the JDK cannot, and should not, provide libraries for every conceivable
> file format or protocol, the JDK philosophy is one of "batteries included",
> which is to say we should be able to write basic programs that use common
> protocols such as HTTP, without having to appeal to third party libraries.
> The Java ecosystem already has plenty of JSON libraries, so inclusion in
> the JDK is largely meant to be a convenience, rather than needing to be the "one
> true" JSON library to meet the needs of all users. Users with specific needs
> are always free to select one of the existing third-party libraries.
>
> ## Goals and requirements
>
> Our primary goal is that the library be simple to use for parsing, traversing,
> and generating conformant JSON documents. Advanced features, such as data
> binding or path-based traversal should be possible to implement as layered
> features, but for simplicity are not included in the core API. We adopt a goal
> that the performance should be "good enough", but where performance
> considerations conflict with simplicity and usability, we will choose in favor
> of the latter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/ab7b3c8f/attachment-0001.htm>