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" <fo...@univ-mlv.fr>
> To: "Brian Goetz" <brian.go...@oracle.com>
> Cc: "Paul Sandoz" <paul.san...@oracle.com>, "core-libs-dev"
> <core-libs-dev@openjdk.org>
> Sent: Friday, May 16, 2025 8:42:47 PM
> Subject: Re: Towards a JSON API for the JDK
>> From: "Brian Goetz" <brian.go...@oracle.com>
>> To: "Remi Forax" <fo...@univ-mlv.fr>
>> Cc: "Paul Sandoz" <paul.san...@oracle.com>, "core-libs-dev"
>> <core-libs-dev@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:fo...@univ-mlv.fr | fo...@univ-mlv.fr ]
>> wrote:
>>> ----- Original Message -----
>>>> From: "Brian Goetz" [ mailto:brian.go...@oracle.com |
>>>> <brian.go...@oracle.com> ]
>>>> To: "Remi Forax" [ mailto:fo...@univ-mlv.fr | <fo...@univ-mlv.fr> ] , "Paul
>>>> Sandoz" [ mailto:paul.san...@oracle.com | <paul.san...@oracle.com> ] Cc:
>>>> "core-libs-dev" [ mailto:core-libs-dev@openjdk.org |
>>>> <core-libs-dev@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
