Towards a JSON API for the JDK

[Paul Sandoz]

It was a design choice to be consistent with each json value having an X, accepting X in on construction and producing X out (notionally) on deconstruction, which leans into pattern matching. Definitely pros/cons to that e.g., we could instead make JonObject implement Map, or do as you suggest [*], both of which adjust how one reasons about the X in and X out.

I would prefer to mostly drive the API design from user ergonomics with pattern matching rather than what is easier for implementations. It’s definitely possible for implementations to optimize (as you posit, such as a concrete implementation extending from Map with a custom implementation), and there is room for improvement in the current implementation we should explore.

Paul.

[*] Although I don’t think we can avoid exposing collection like semantics, since it requires iteration to produce the Map containing all the entries from a default method, so might as well expose Map directly.


> On May 21, 2025, at 9:01 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Hi Paul,
> I like the emphasis on minimality, and extensibility of the proposed API.
> 
> One comment/question is why the API choses to expose Json arrays and objects as List/Maps respectively, instead of e.g. providing accessor to the object members/array elements.
> 
> E.g. it seems to me that creating a Map from a JSON object is a potentially expensive operation (although perhaps maybe an implementor could implement some kind of lazy list/map under the hood).
> 
> If the "minimal" contract only required basic element (for arrays) or key/val (for objects) accessors, perhaps this will might leave more room for implementors to support such accessors as they see fit? And we could still have default methods which could use the accessor to provide a List/Map view of the json array/object.
> 
> Cheers
> Maurizio