<div dir="ltr"><div>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. </div><div><br></div><div>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: </div><div><br></div><div>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. <br></div><div><br></div><div>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.</div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Thank you</div><div>Swaranga</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 19, 2025 at 2:56 PM <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div><br></div><hr id="m_6327169673589306746m_3434843368809170960zwchr"><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Paul Sandoz" <<a href="mailto:paul.sandoz@oracle.com" target="_blank">paul.sandoz@oracle.com</a>><br><b>To: </b>"Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>><br><b>Cc: </b>"Brian Goetz" <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>>, "core-libs-dev" <<a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a>><br><b>Sent: </b>Monday, May 19, 2025 11:18:26 PM<br><b>Subject: </b>Re: Towards a JSON API for the JDK<br></blockquote></div><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">
<div>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.</div></blockquote><div><br></div><div>List is such a good example.</div><div>For a List, like for a JsonValue, you have no idea if the implementation is mutable or not,</div><div>so you can use a defensive copy using List.copyOf() (or Collections.unmodifiableList(new ArrayList<>(list)) in the older version of Java).</div><div><br></div><div>How to do a defensive copy of a JsonValue ?</div><div><br></div><div>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.</div><div>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.</div><div>With the actual design, you have no way to know if a JSON document is valid.</div><div><br></div><div>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,</div><div>hence the idea of implementing real ADTs using records.</div><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">
<div>
<div>
<div><br>
</div>
<div>Paul.</div></div></div></blockquote><div><br></div><div>Rémi</div><div><br></div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div><div><div><br id="m_6327169673589306746m_3434843368809170960lineBreakAtBeginningOfMessage">
<div><br>
<blockquote>
<div>On May 19, 2025, at 1:56 PM, <a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a> wrote:</div>
<br>
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<br>
<br>
</div>
<hr id="m_6327169673589306746m_3434843368809170960zwchr" style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">
<b>From:</b>"Paul Sandoz" <<a href="mailto:paul.sandoz@oracle.com" target="_blank">paul.sandoz@oracle.com</a>><br>
<b>To:</b>"Remi Forax" <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>><br>
<b>Cc:</b>"Brian Goetz" <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>>, "core-libs-dev" <<a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a>><br>
<b>Sent:</b>Monday, May 19, 2025 10:02:50 PM<br>
<b>Subject:</b>Re: Towards a JSON API for the JDK<br>
</blockquote>
</div>
<div style="font-family:arial,helvetica,sans-serif;font-size:16px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt">
<br id="m_6327169673589306746m_3434843368809170960lineBreakAtBeginningOfMessage">
<div><br>
<blockquote>
<div>On May 19, 2025, at 8:16 AM, Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:</div>
<br>
<div>
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:12pt">
<div>Okay,</div>
<div>i've taken a look to the design and this is not pretty.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
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.</div>
<div><br>
</div>
<div><br>
<blockquote>
<div>
<div>
<div style="font-family:arial,helvetica,sans-serif;font-size:12pt">
<div>The main issue is that the javadoc claims that</div>
<div>  "Both<code>JsonValue</code>instances and their underlying values are immutable."</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div>You can not claim that JsonValue instances are immutable while obviously they are not.</div>
<div>You can not claim that JsonValue subtypes are ADTs while obviously JsonValue is not algebraic.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>The minute I write a method that takes a JsonValue as parameter i'm writing unsafe code,<br>
</div>
<div><br>
</div>
<div>You are hoping that nobody will ever extend JsonValue subtypes, that's wishful thinking, this is not a safe design ... this is not pretty.</div>
<div><br>
</div>
<div>Rémi</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div><br></blockquote></div></div></div></blockquote></div>