Towards a JSON API for the JDK

[Remi Forax]

Okay, 
i've taken a look to the design and this is not pretty. 

The main issue is that the javadoc claims that 
"Both JsonValue instances and their underlying values are immutable." 
but at the same time any subtypes of JsonValue is non-sealed so anyone can implement let say JsonString and adds it's own mutable implementation. 

Because the hierarchy is non sealed, it also means that it is easy to create JsonValue that are invalid, 
for example 

var funJsonNumber = new JsonNumber() { 
public Number toNumber () { 
return Double . NaN ; 
} 
public BigDecimal toBigDecimal () { 
throw new UnsupportedOperationException(); 
} 
public String toString () { 
return "NaN" ; 
} 
}; 

var json = Json.fromUntyped( List . of ( funJsonNumber )); 

For me, the Json hierarchy should be implemented with true ADTs, with all subtypes of JsonValue being records. 

regards, 
Rémi 

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

>> 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/20250519/5e5dcd0d/attachment-0001.htm>