> It’s a not a goal to solve the dependency problem (a very hard problem!) even in a narrow sense.
That was only an example where a data-binding API would be useful - it wasn't a meant to be the only use-case or even a suggestion that it should be solved in the general case. > A potential advantage that we (the OpenJDK community) can more easily do is devise an API that resonates with direction the Java platform is heading, specifically around the pattern matching and serialization 2.0 Right, but most of the discussion here seems to be on the low level tree API and how one might navigate it (perhaps using pattern matching). I am not seeing any discussion on the serialization/deserialization or any reasoning why that is not the goal of the new JEP. Basically a very focused and narrow API: ``` var jsonStr = "..." var myRecord = Json.deserialize(jsonString, UserRecord.class); //and a few other variants var serialized = Json.serialize(myRecord) ``` This leaves the tree API open to reimplementation later when pattern matching and other features are firmly in place in the JDK. I am making a case that this would be more immediately useful for the most common and simpler cases. Regards Swaranga On Tue, May 20, 2025 at 11:49 AM Paul Sandoz <paul.san...@oracle.com> wrote: > JEP 198 will likely be withdrawn and a new JEP will be drafted aligned > with the document sent in this email thread. > > It’s a not a goal to solve the dependency problem (a very hard problem!) > even in a narrow sense. > > A potential advantage that we (the OpenJDK community) can more easily do > is devise an API that resonates with direction the Java platform is > heading, specifically around the pattern matching and serialization 2.0, > and potentially so with further out features. This has a number of > advantages: > > 1. It should enable us to devise a simpler API that naturally gains more > power as it is used in combination with those features; > 2. It provides feedback to those features and perhaps the other way around > too; and > 3. It provides a template for others to copy in their own libraries. > > Paul. > > > On May 20, 2025, at 12:53 AM, Swaranga Sarma <sarma.swara...@gmail.com> > wrote: > > > > 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 > >
