Hello, I am not a language or a library developer by any means but I wanted to offer my perspective as a prospective user of such an API.
I am sure this was considered but feel compelled to raise it regardless - instead of the low level tree API (and baking whatever design choice is made forever into the JDK), was a higher level data binding API considered while keeping any low-level tree implementation private to the JDK? Basically a way to take a Json document (String/Reader/...) and deserialize it into an instance of a user-defined Record (and vice versa). From my perspective, this would be a more useful addition for the simpler and most common cases and if there are more complex requirements around flexibility/performance then there are lots of 3rd party options available in Java. I do not have data to back my hunch that this will be more valuable but I am offering my real production use-case where I would find it useful: I have a bunch of rest APIs for which my callers want me to vend a Java client that has the Java POJO classes for the request and response shapes; they don't want to write it by hand which is a reasonable ask. I usually create a Java library that uses the standard Java Http client under the hood to make the calls and serialize and deserialize the DTOs using Jackson. The problem is that as soon as I add Jackson to the client library's dependencies, it is no longer a zero-runtime dependency library and the callers have to deal with multiple versions, version incompatibility etc (in case they also use Jackson in the client app). With a Json api with support for data binding in the standard library, I could vend a very thin zero additional dependencies Java client to my callers. This is not quite what JEP 198 is stating as its goals but I am also not sure if this discussion is towards an implementation for that JEP. Thank you Swaranga On Mon, May 19, 2025 at 2:56 PM <fo...@univ-mlv.fr> wrote: > > > ------------------------------ > > *From: *"Paul Sandoz" <paul.san...@oracle.com> > *To: *"Remi Forax" <fo...@univ-mlv.fr> > *Cc: *"Brian Goetz" <brian.go...@oracle.com>, "core-libs-dev" < > core-libs-dev@openjdk.org> > *Sent: *Monday, May 19, 2025 11:18:26 PM > *Subject: *Re: Towards a JSON API for the JDK > > Those extending the non-sealed subtypes of JsonValue must conform to the > requirements that are specified. The current documentation could be more > clearly written as to what those requirements are. Of course we cannot > enforce those requirements any more than we can enforce the requirements > specified for implementations of List. > > > List is such a good example. > For a List, like for a JsonValue, you have no idea if the implementation > is mutable or not, > so you can use a defensive copy using List.copyOf() (or > Collections.unmodifiableList(new ArrayList<>(list)) in the older version of > Java). > > How to do a defensive copy of a JsonValue ? > > The other issue I see is lazyness in Json.parse(). The API is restricted > to String/char[], so restricted to JSON document that are not big. > If the document is not big, lazyness usually make things slower and it > also delays the moment you know if the document is a valid JSON document or > not. > With the actual design, you have no way to know if a JSON document is > valid. > > If you combine both things, the fact that you have a big list of > requirements for each subtypes and eager parsing, you are not far from > having only one implementation possible, > hence the idea of implementing real ADTs using records. > > > Paul. > > > Rémi > > > > On May 19, 2025, at 1:56 PM, fo...@univ-mlv.fr wrote: > > > > ------------------------------ > > *From:*"Paul Sandoz" <paul.san...@oracle.com> > *To:*"Remi Forax" <fo...@univ-mlv.fr> > *Cc:*"Brian Goetz" <brian.go...@oracle.com>, "core-libs-dev" < > core-libs-dev@openjdk.org> > *Sent:*Monday, May 19, 2025 10:02:50 PM > *Subject:*Re: Towards a JSON API for the JDK > > > > On May 19, 2025, at 8:16 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > > Okay, > i've taken a look to the design and this is not pretty. > > > That seems an exaggerated statement to me. It's a trade-off, a compromise, > allowing others to implement their own parsers, perhaps from non-textual > representations. So of course we cannot enforce certain constraints and we > need to specify how implementations must behave. > > > The main issue is that the javadoc claims that > "BothJsonValueinstances and their underlying values are immutable." > but at the same time any subtypes of JsonValue is non-sealed so anyone can > implement let say JsonString and adds it's own mutable implementation. > > > You can not claim that JsonValue instances are immutable while obviously > they are not. > You can not claim that JsonValue subtypes are ADTs while obviously > JsonValue is not algebraic. > > You allow anybody to write their own class inside the JsonValue hierarchy, > so there is no safety, strings can be not escaped correctly, number can > represent invalid values, etc. > > The minute I write a method that takes a JsonValue as parameter i'm > writing unsafe code, > > You are hoping that nobody will ever extend JsonValue subtypes, that's > wishful thinking, this is not a safe design ... this is not pretty. > > Rémi > > > >
