Towards a JSON API for the JDK

[forax at univ-mlv.fr]

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

> Those extending the non-sealed subtypes of JsonValue must conform to the
> requirements that are specified. The current documentation could be more
> clearly written as to what those requirements are. Of course we cannot enforce
> those requirements any more than we can enforce the requirements specified for
> implementations of List.

List is such a good example. 
For a List, like for a JsonValue, you have no idea if the implementation is mutable or not, 
so you can use a defensive copy using List.copyOf() (or Collections.unmodifiableList(new ArrayList<>(list)) in the older version of Java). 

How to do a defensive copy of a JsonValue ? 

The other issue I see is lazyness in Json.parse(). The API is restricted to String/char[], so restricted to JSON document that are not big. 
If the document is not big, lazyness usually make things slower and it also delays the moment you know if the document is a valid JSON document or not. 
With the actual design, you have no way to know if a JSON document is valid. 

If you combine both things, the fact that you have a big list of requirements for each subtypes and eager parsing, you are not far from having only one implementation possible, 
hence the idea of implementing real ADTs using records. 

> Paul.

Rémi 

>> On May 19, 2025, at 1:56 PM, forax at univ-mlv.fr wrote:

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

>>>> On May 19, 2025, at 8:16 AM, Remi Forax <forax at univ-mlv.fr> wrote:

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

>>> That seems an exaggerated statement to me. It's a trade-off, a compromise,
>>> allowing others to implement their own parsers, perhaps from non-textual
>>> representations. So of course we cannot enforce certain constraints and we need
>>> to specify how implementations must behave.

>>>> 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.

>> You can not claim that JsonValue instances are immutable while obviously they
>> are not.
>> You can not claim that JsonValue subtypes are ADTs while obviously JsonValue is
>> not algebraic.

>> You allow anybody to write their own class inside the JsonValue hierarchy, so
>> there is no safety, strings can be not escaped correctly, number can represent
>> invalid values, etc.

>> The minute I write a method that takes a JsonValue as parameter i'm writing
>> unsafe code,

>> You are hoping that nobody will ever extend JsonValue subtypes, that's wishful
>> thinking, this is not a safe design ... this is not pretty.

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