I think we should pull apart those concerns a little: I am of the opinion that the API is more important at this stage than the actual implementation, save for the places where having an API of a particular shape mandates implementation choices.
> The JsonNull/JsonNumber/JsonString/JsonValue here should not be designed like this, which will cause trouble to users and affect performance. Can you go very deep on why you think this is the case? There are properties of this today (i.e. indirection due to a lack of value classes) which can be resolved in time, but others which are intrinsic. > 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. So that is what toUntyped provides in this draft - having a pass-through with the explicit hierarchy. Can you also elaborate on the use cases you have seen for the "direct Java type mapping?" What APIs expect these generic structures? On Fri, May 16, 2025 at 11:42 PM wenshao <shaojin.we...@alibaba-inc.com> wrote: > 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 wrote: > > ----- Original Message ----- > > From: "Brian Goetz" <brian.go...@oracle.com> <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> <fo...@univ-mlv.fr>, "Paul Sandoz" > <paul.san...@oracle.com> <paul.san...@oracle.com> > Cc: "core-libs-dev" <core-libs-dev@openjdk.org> <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 > > > > > > > > > > >
