<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Okay,</div><div>i've taken a look to the design and this is not pretty.</div><div><br data-mce-bogus="1"></div><div>The main issue is that the javadoc claims that</div><div> "Both <code>JsonValue</code> instances and their underlying values are immutable."</div><div>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.</div><div><br data-mce-bogus="1"></div><div>Because the hierarchy is non sealed, it also means that it is easy to create JsonValue that are invalid,</div><div>for example</div><div><br data-mce-bogus="1"></div><div><div style="background-color: #ffffff; color: #080808;" data-mce-style="background-color: #ffffff; color: #080808;"><pre style="font-family: 'JetBrains Mono',monospace; font-size: 9.8pt;" data-mce-style="font-family: 'JetBrains Mono',monospace; font-size: 9.8pt;"><span style="color: #0033b3;" data-mce-style="color: #0033b3;">var </span><span style="color: #000000;" data-mce-style="color: #000000;">funJsonNumber </span>= <span style="color: #0033b3;" data-mce-style="color: #0033b3;">new </span>JsonNumber() {<br> <span style="color: #0033b3;" data-mce-style="color: #0033b3;">public </span><span style="color: #000000;" data-mce-style="color: #000000;">Number </span><span style="color: #00627a;" data-mce-style="color: #00627a;">toNumber</span>() {<br> <span style="color: #0033b3;" data-mce-style="color: #0033b3;">return </span><span style="color: #000000;" data-mce-style="color: #000000;">Double</span>.<span style="color: #871094; font-style: italic;" data-mce-style="color: #871094; font-style: italic;">NaN</span>;<br> }<br> <span style="color: #0033b3;" data-mce-style="color: #0033b3;">public </span><span style="color: #000000;" data-mce-style="color: #000000;">BigDecimal </span><span style="color: #00627a;" data-mce-style="color: #00627a;">toBigDecimal</span>() {<br> <span style="color: #0033b3;" data-mce-style="color: #0033b3;">throw new </span>UnsupportedOperationException();<br> }<br> <span style="color: #0033b3;" data-mce-style="color: #0033b3;">public </span><span style="color: #000000;" data-mce-style="color: #000000;">String </span><span style="color: #00627a;" data-mce-style="color: #00627a;">toString</span>() {<br> <span style="color: #0033b3;" data-mce-style="color: #0033b3;">return </span><span style="color: #067d17;" data-mce-style="color: #067d17;">"NaN"</span>;<br> }<br>};<br><br><span style="color: #0033b3;" data-mce-style="color: #0033b3;">var </span><span style="color: #000000;" data-mce-style="color: #000000;">json </span>= Json.fromUntyped(<span style="color: #000000;" data-mce-style="color: #000000;">List</span>.<span style="font-style: italic;" data-mce-style="font-style: italic;">of</span>(<span style="color: #000000;" data-mce-style="color: #000000;">funJsonNumber</span>));</pre></div></div><div><br data-mce-bogus="1"></div><div>For me, the Json hierarchy should be implemented with true ADTs, with all subtypes of JsonValue being records.</div><div><br data-mce-bogus="1"></div><div>regards,</div><div>Rémi</div><div><br data-mce-bogus="1"></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>To: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>Cc: </b>"Paul Sandoz" <paul.sandoz@oracle.com>, "core-libs-dev" <core-libs-dev@openjdk.org><br><b>Sent: </b>Friday, May 16, 2025 8:42:47 PM<br><b>Subject: </b>Re: Towards a JSON API for the JDK<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><br><br><hr id="zwchr"><div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"Paul Sandoz" <paul.sandoz@oracle.com>, "core-libs-dev" <core-libs-dev@openjdk.org><br><b>Sent: </b>Friday, May 16, 2025 7:46:09 PM<br><b>Subject: </b>Re: Towards a JSON API for the JDK<br></blockquote></div><div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4" face="monospace">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.)</font></blockquote><br><div>Reading the implementation is on my TODO list :)</div><br><div>Rémi</div><br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>
<br>
<div class="moz-cite-prefix">On 5/16/2025 10:35 AM,
<a class="moz-txt-link-abbreviated" href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a> wrote:<br>
</div>
<blockquote cite="mid:1544852119.267640166.1747406109120.JavaMail.zimbra@univ-eiffel.fr">
<pre class="moz-quote-pre">----- Original Message -----
</pre>
<blockquote>
<pre class="moz-quote-pre">From: "Brian Goetz" <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com" target="_blank"><brian.goetz@oracle.com></a>
To: "Remi Forax" <a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr" target="_blank"><forax@univ-mlv.fr></a>, "Paul Sandoz" <a class="moz-txt-link-rfc2396E" href="mailto:paul.sandoz@oracle.com" target="_blank"><paul.sandoz@oracle.com></a>
Cc: "core-libs-dev" <a class="moz-txt-link-rfc2396E" href="mailto:core-libs-dev@openjdk.org" target="_blank"><core-libs-dev@openjdk.org></a>
Sent: Friday, May 16, 2025 2:53:18 PM
Subject: Re: Towards a JSON API for the JDK
</pre>
</blockquote>
<blockquote>
<pre class="moz-quote-pre">On 5/15/2025 5:27 PM, Remi Forax wrote:
</pre>
<blockquote>
<pre class="moz-quote-pre">It's not clear to me why JsonArray (for example) has to be an interface instead
of a record ?
</pre>
</blockquote>
<pre class="moz-quote-pre">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.
</pre>
</blockquote>
<pre class="moz-quote-pre">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
</pre>
</blockquote>
</blockquote></div></div><br></blockquote></div></div></body></html>