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 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/b161488d/attachment-0001.htm>