On May 19, 2025, at 8:16 AM, Remi Forax <[email protected]> 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.
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.
Not doing that for reasons Brian has already explained.
Paul.
