Towards a JSON API for the JDK

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Paul Sandoz" <paul.sandoz at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.org>
> Sent: Friday, May 16, 2025 7:46:09 PM
> Subject: Re: Towards a JSON API for the JDK

> If you read the implementation, you'll see that significant laziness is indeed
> possible for JsonObject and JsonArray, even while doing eager validation. (Of
> course, one can shift the balance to achieve various other tradeoffs.)
Reading the implementation is on my TODO list :) 

Rémi 

> On 5/16/2025 10:35 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> ----- Original Message -----

>>> From: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ] , "Paul
>>> Sandoz" [ mailto:paul.sandoz at oracle.com | <paul.sandoz at oracle.com> ] Cc:
>>> "core-libs-dev" [ mailto:core-libs-dev at openjdk.org |
>>> <core-libs-dev at openjdk.org> ] Sent: Friday, May 16, 2025 2:53:18 PM
>>> Subject: Re: Towards a JSON API for the JDK

>>> On 5/15/2025 5:27 PM, Remi Forax wrote:

>>>> It's not clear to me why JsonArray (for example) has to be an interface instead
>>>> of a record ?

>>> Oh, you know the answer to this.  A record limits us to a single
>>> implementation with a rigid representation.  Behind an interface, we can
>>> hide lazy parsing and inflation, wrapping other representations to
>>> reduce copies, etc.

>> First, let me refine the question.
>> There are only 4 kinds of JSON values that benefit from having different
>> representations, object, array, string and number.
>> For object and array, both takes an interface as parameter (Map or List) so
>> JsonArray and JSonObject do not need to be themselves interfaces.

>> So the only values where it may be worth to be modeled using an interface are
>> JsonString and JsonNumber, because as you said, you can do "lazy" parsing.

>> But delaying the parsing of the content has the side effect that even if
>> Json.parse() did not throw an exception, it does not mean that the JSON text is
>> valid, an exception may be thrown later.

>> Now, for me, this library is more about being simple and safe than fast.
>> If you agree with that, delaying the parsing is not a good idea, thus JSON
>> values should be modeled using records and not interfaces.

>> regards,
>> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250516/1b08c103/attachment.htm>