Towards a JSON API for the JDK

[Ethan McCue]

What I mean by central in this context isn't that it's at the core of
things and features are built on top of it - as you note it is a valid
transformation of the hierarchy.

What I mean is that absent other construction/deconstruction apis it is the
most convenient avenue for those tasks. So code using the API would trend
towards using it. See Remi's usage of fromUntyped elsewhere in the
discussion tree.

The thing that the language doesn't have yet is patterns. We have all the
mechanism for creating objects. The broad issue I see is that, if we take
the view that >in general< deconstruction should be the dual of
construction - the mechanics for construction should probably be influenced
by how you want people pulling these things apart.

Basic example - JsonString.of - that is null hostile for good reason, but
it is very easy to imagine wanting to write code that deals uniformly with
absent, null, and string values for a field in an object.

So that puts a pressure - beyond creation ergonomics - on a Json.of that is
null-tolerant. Since that would be a good place for a dual pattern for
pulling out a possibly nullable object member.

(but still wouldn't solve for absent ones - I have a doc somewhere with
like 15 options none of which inspire joy and many of which are conditional
on exactly how patterns ship)

On Mon, May 19, 2025, 3:55 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> >
> > This is part of why fromUntyped/toUntyped is uncomfortable - it's
> choosing one particular encoding of JSON and making it central to the API.
> Is that really the most important encoding?
> >
>
>
> It's one opinionated kind, a simple bi-directional mapping
> (embedding-projection pair) based on what the json values contain. The
> implementations can be entirely written less than 100 lines of code using
> the public API (there are more lines for the documentation). Users can
> easily write their own and can serve as an example with a bit more
> exposition in the documentation. The methods could be removed and it would
> not affect anything else, so it's not fundamental nor central.
>
> Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/6bf0f1b1/attachment-0001.htm>