> 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, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] wrote: >> ----- Original Message ----- >>> From: "Brian Goetz" [ mailto:brian.go...@oracle.com | >>> <brian.go...@oracle.com> ] >>> To: "Remi Forax" [ mailto:fo...@univ-mlv.fr | <fo...@univ-mlv.fr> ] , "Paul >>> Sandoz" [ mailto:paul.san...@oracle.com | <paul.san...@oracle.com> ] Cc: >>> "core-libs-dev" [ mailto: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
