Re: What is meant by "document context" in JEP 198?
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 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 >
Re: What is meant by "document context" in JEP 198?
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
Re: What is meant by "document context" in JEP 198?
...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 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 >
Re: What is meant by "document context" in JEP 198?
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
Re: What is meant by "document context" in JEP 198?
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?
On Thu, Nov 24, 2022 at 8:55 PM Ethan McCue wrote:
> I'm reading JEP 198 and sketching out what an implementation could look
> like pursuant to this old conversation.
>
> https://mail.openjdk.org/pipermail/discuss/2020-April/005401.html
>
> My biggest question right now is what does the JEP mean exactly by
> "document context"
>
>
>- Parsing APIs which allow a choice of parsing token stream, event
>(includes document hierarchy context) stream, or immutable tree
>representation views of JSON documents and data streams.
>
>
>
> So token stream I understand as something akin to
>
> sealed interface Token {
> record StartArray() implements Token {}
> record EndArray() implements Token {}
> record StartObject() implements Token {}
> record EndObject() implements Token {}
> record Number(Json.Number value) implements Token {}
> record String(Json.String value) implements Token {}
> record True() implements Token {}
> record False() implements Token {}
> record Null() implements Token {}
> }
>
> Which matches up with the model in
> https://fasterxml.github.io/jackson-core/javadoc/2.7/com/fasterxml/jackson/core/JsonToken.html
>
> And an immutable tree representation as akin to
>
> sealed interface Json {
> sealed interface Array extends Json, List ...
> sealed interface Object extends Json, Map ...
> sealed abstract class Number extends java.lang.Number implements Json
> ...
> sealed interface String extends Json, CharSequence ...
> sealed interface Boolean ...
> sealed interface Null extends Json ...
> }
>
> Which, ignoring the open questions of
> * Does the immutable tree need to be eagerly realized?
> * Do we need to wait for valhalla to land
> * Do we need to wait for full pattern matching to land
>
> (because they make me sad)
>
> I'm still unsure what information needs to be included in an "Event"
> stream that would constitute "document context". Is it pointers to parent
> collections? The current "Path"?
>
> sealed interface PathElement {
> record Field(String fieldName) implements PathElement {}
> record Index(int index) implements PathElement {}
> }
>
>
>
>
What is meant by "document context" in JEP 198?
I'm reading JEP 198 and sketching out what an implementation could look
like pursuant to this old conversation.
https://mail.openjdk.org/pipermail/discuss/2020-April/005401.html
My biggest question right now is what does the JEP mean exactly by
"document context"
- Parsing APIs which allow a choice of parsing token stream, event
(includes document hierarchy context) stream, or immutable tree
representation views of JSON documents and data streams.
So token stream I understand as something akin to
sealed interface Token {
record StartArray() implements Token {}
record EndArray() implements Token {}
record StartObject() implements Token {}
record EndObject() implements Token {}
record Number(Json.Number value) implements Token {}
record String(Json.String value) implements Token {}
record True() implements Token {}
record False() implements Token {}
record Null() implements Token {}
}
Which matches up with the model in
https://fasterxml.github.io/jackson-core/javadoc/2.7/com/fasterxml/jackson/core/JsonToken.html
And an immutable tree representation as akin to
sealed interface Json {
sealed interface Array extends Json, List ...
sealed interface Object extends Json, Map ...
sealed abstract class Number extends java.lang.Number implements Json
...
sealed interface String extends Json, CharSequence ...
sealed interface Boolean ...
sealed interface Null extends Json ...
}
Which, ignoring the open questions of
* Does the immutable tree need to be eagerly realized?
* Do we need to wait for valhalla to land
* Do we need to wait for full pattern matching to land
(because they make me sad)
I'm still unsure what information needs to be included in an "Event" stream
that would constitute "document context". Is it pointers to parent
collections? The current "Path"?
sealed interface PathElement {
record Field(String fieldName) implements PathElement {}
record Index(int index) implements PathElement {}
}
