That tracks.

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.

I'd say that the JEP as written could use some rework even before its "time
has come".

* Goals like "useful subset for Java ME" don't feel relevant anymore.
* 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"
* "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.

[1]:
https://mail.openjdk.org/pipermail/core-libs-dev/2022-September/094231.html
[2]:
https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html

On Fri, Nov 25, 2022 at 9:08 AM Alan Bateman <alan.bate...@oracle.com>
wrote:

> On 25/11/2022 13:27, Ethan McCue wrote:
>
> ...huh
>
> >>  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
> None of those seem like they would have been using nashorn in the past, so i 
> wonder what this is referring to.
>
>
> 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.
>
> -Alan
>
> [1] https://mail.openjdk.org/pipermail/discuss/2020-April/005398.html
> [2] https://bugs.openjdk.org/browse/JDK-8242934
>

Reply via email to