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