<div class="__aliyun_email_body_block"><div style="color: 0070c0;font-size: 14px;font-family: Tahoma, Arial, STHeitiSC-Light, SimSun"><div style="clear: both;"><span style="font-size: 14px; font-family: Tahoma, Arial, STHeitiSC-Light, SimSun;"><span >As the author of a popular json library (fastjson/fastjson2), I think the current design is not good, not easy to use, and the performance is not good.</span></span><div style="clear: both;">The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed like this, which will cause trouble to users and affect performance.</div><div style="clear: both;"><br ></div><div style="clear: both;">For simple types of JSON, you can directly use Java type mapping, such as:</div><div style="clear: both;">null -> null</div><div style="clear: both;">string -> string</div><div style="clear: both;">number -> integer/long/bigint/float/double, select the mapping type through configuration, or according to a rule we set.</div><div style="clear: both;"><br ></div><div style="clear: both;"><br ></div><div style="clear: both;"><span >Array and Object types should also support more flexible mapping:</span></div><div style="clear: both;">object -> JsonObject or Map (HashMap/LinkedHashMap/ConcurrentHashMap...)</div><div ><span >array -> JsonArray or List(ArrayList/LinkedList/...) or typed-array</span></div><div ><span ><br ></span></div><div ><span ><br ></span></div><div ><span ><span >Lazy parsing should not be used because it will degrade performance. If we need to support partial parsing, we can provide a skip api, and later we can provide a jsonpath api, or support passing in type/JsonSchema information and parsing according to the schema.</span></span></div><div ><span ><span ><br ></span></span></div><div ><span ><span ><span >Also, if we want better performance, both Parser and Generator should provide both UTF16 and UTF8 implementations.</span></span></span></div></div><blockquote style="margin-right: 0px; margin-top: 0px; margin-bottom: 0px; font-family: Tahoma, Arial, STHeiti, SimSun; font-size: 14px; color: rgb(0, 0, 0);"><div style="clear: both;">------------------------------------------------------------------</div><div style="clear: both;">发件人：forax <forax@univ-mlv.fr></div><div style="clear: both;">发送时间：2025年5月17日(周六) 02:43</div><div style="clear: both;">收件人：Brian Goetz<brian.goetz@oracle.com></div><div style="clear: both;">抄 送：Paul Sandoz<paul.sandoz@oracle.com>; "core-libs-dev"<core-libs-dev@openjdk.org></div><div style="clear: both;">主 题：Re: Towards a JSON API for the JDK</div><div style="clear: both;"><br ></div><div class=" __aliyun_node_has_color" style="font-family: arial, helvetica, sans-serif; font-size: 16px; color: rgb(0, 0, 0);"><div ><br ></div><div ><br ></div><hr id="zwchr"><div ><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 ></div><div ><div style="margin: 16px 40px;"><span style="font-family: monospace; font-size: 18px;">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.)</span></div><div ><br ></div><div >Reading the implementation is on my TODO list :)</div><div ><br ></div><div >Rémi</div><div ><br ></div><div style="margin: 16px 40px;"><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>
<pre class="moz-quote-pre">----- Original Message -----
</pre>
<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>
<pre class="moz-quote-pre">On 5/15/2025 5:27 PM, Remi Forax wrote:
</pre>
<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>
<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>
<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>
<br ><br ></div></div></div></blockquote></div></div>