<div dir="ltr">...huh <br><br><pre style="color:rgb(0,0,0)">>><span style="font-family:Arial,Helvetica,sans-serif">  </span>The recent removal of Nashorn has indicated several places were
>> javascript were used in the JDK mainly due to it's built-in support for
>> parsing JSON<i>

</i><font face="arial, sans-serif">None of those seem like they would have been using nashorn in the past, so i wonder what this is referring to.</font></pre></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 25, 2022 at 2:52 AM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</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">On 25/11/2022 02:04, Ethan McCue wrote:<br>
> I suppose while I'm asking questions - what exactly are the parts of <br>
> the JDK making use of ad-hoc json? Maybe we could ship *something* as <br>
> a jdk.internal module for those use cases?<br>
><br>
JEP 198 pre-dates records, sealed classes, pattern matching, ... and I <br>
will assume will re-drafted or replaced when the time comes.<br>
<br>
Right now, I don't think there are too many places in the JDK that <br>
interact with JSON.  The `jfr` tool can print the records from a JFR <br>
recording as a JSON document. The HotSpotDiagnosMXBean API and `jcmd` <br>
tool can generate a thread dump as a JSON document. I think the only <br>
parsing at this time is the HotSpot compiler control (JEP 165) where <br>
directives file is a subset of JSON but that is implemented in C++ in <br>
libjvm and probably not what you are looking for.<br>
<br>
There are number of places in the JDK that read configuration and it <br>
might be that some of these could consume configuration in JSON in the <br>
future.<br>
<br>
-Alan<br>
</blockquote></div>