<div dir="ltr">That tracks.<br><br>The component I, personally, might want JSON available internally for is an artifact resolution API [1]. Gradle's module metadata is out there in the world and could be worth consuming [2]. That's neither here nor there though.<br><br>I'd say that the JEP as written could use some rework even before its "time has come".<br><br>* Goals like "useful subset for Java ME" don't feel relevant anymore.<br>* Unstated goals that seem implicit in how folks have talked about potential APIs, like "improve over JSR-353" or "obviate ecosystem desire for JAXB type data binding"<br>* "Goals" that seem derived more from the properties of whatever prototype implementation the JEP had than a core "user story". A split token/event/immutable tree API is just one possible solution to problems like big documents and letting power users avoid allocations.<br><br>[1]: <a href="https://mail.openjdk.org/pipermail/core-libs-dev/2022-September/094231.html">https://mail.openjdk.org/pipermail/core-libs-dev/2022-September/094231.html</a><br>[2]: <a href="https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html">https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 25, 2022 at 9:08 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">

  
  <div>
    On 25/11/2022 13:27, Ethan McCue wrote:<br>
    <blockquote type="cite">
      
      <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>
    </blockquote>
    <br>
    The quoted text seems to be from a mail that Magnus Ihse Bursie sent
    to the discuss list in 2020 [1]. It's the same date that JDK-8242934
    [1] was created so it may be that the mail was (at least partly)
    prompted by the need to change the test  for`jfr print --json`. The
    test for that feature used to use Nashorn and had to be changed to
    use a JSON parser in the test suite. The JSON parser was
    subsequently moved to test/lib/jdk/test/lib/json/JSONValue.java so
    it could be used by other tests.<br>
    <br>
    -Alan<br>
    <br>
    [1]
    <a href="https://mail.openjdk.org/pipermail/discuss/2020-April/005398.html" target="_blank">https://mail.openjdk.org/pipermail/discuss/2020-April/005398.html</a><br>
    [2] <a href="https://bugs.openjdk.org/browse/JDK-8242934" target="_blank">https://bugs.openjdk.org/browse/JDK-8242934</a><br>
  </div>

</blockquote></div>