Towards a JSON API for the JDK

Paul Sandoz paul.sandoz at oracle.com
Mon May 19 20:02:50 UTC 2025



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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250519/229b47e2/attachment.htm>


More information about the core-libs-dev mailing list