> From: "Brian Goetz" <[email protected]> > To: "Remi Forax" <[email protected]> > Cc: "Paul Sandoz" <[email protected]>, "core-libs-dev" > <[email protected]> > 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, [ mailto:[email protected] | [email protected] ] wrote: >> ----- Original Message ----- >>> From: "Brian Goetz" [ mailto:[email protected] | >>> <[email protected]> ] >>> To: "Remi Forax" [ mailto:[email protected] | <[email protected]> ] , "Paul >>> Sandoz" [ mailto:[email protected] | <[email protected]> ] Cc: >>> "core-libs-dev" [ mailto:[email protected] | >>> <[email protected]> ] 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
