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.
The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed like
this, which will cause trouble to users and affect performance.
For simple types of JSON, you can directly use Java type mapping, such as:
null -> null
string -> string
number -> integer/long/bigint/float/double, select the mapping type through
configuration, or according to a rule we set.
Array and Object types should also support more flexible mapping:
object -> JsonObject or Map (HashMap/LinkedHashMap/ConcurrentHashMap...)
array -> JsonArray or List(ArrayList/LinkedList/...) or typed-array
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.
Also, if we want better performance, both Parser and Generator should provide
both UTF16 and UTF8 implementations.
------------------------------------------------------------------
发件人：forax <fo...@univ-mlv.fr>
发送时间：2025年5月17日(周六) 02:43
收件人：Brian Goetz<brian.go...@oracle.com>
抄 送：Paul Sandoz<paul.san...@oracle.com>;
"core-libs-dev"<core-libs-dev@openjdk.org>
主 题：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, fo...@univ-mlv.fr <mailto:fo...@univ-mlv.fr > wrote:
----- Original Message ----- From: "Brian Goetz" <brian.go...@oracle.com>
<mailto:brian.go...@oracle.com > To: "Remi Forax" <fo...@univ-mlv.fr>
<mailto:fo...@univ-mlv.fr >, "Paul Sandoz" <paul.san...@oracle.com>
<mailto:paul.san...@oracle.com > Cc: "core-libs-dev"
<core-libs-dev@openjdk.org> <mailto: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
