Revival of JEP 198 (Light-Weight JSON API)?

[forax at univ-mlv.fr]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "discuss" <discuss at openjdk.java.net>
> Envoyé: Samedi 18 Avril 2020 09:53:58
> Objet: Re: Revival of JEP 198 (Light-Weight JSON API)?

> Representing a JSON tree as a tree of Valhalla values (yes, they
> can come in trees!) is very much worth investigating IMO.  The nearest
> approximation before Valhalla would be to design a JSON node model
> which consists only of (or mainly of) value-based classes.  Or, perhaps
> Valhalla-style cursors (iterators which say x=x.next() instead of x.next())
> can express a walk over a mutable tree, whose structure is hidden (and
> thus can be materialized lazily or streamily).  The nearest approximation
> to that would be an iterator-style API, where one object updates itself
> in place.
> 
> One other thought:  Sometimes that parsing and unparsing logic
> for a syntax like JSON or XML can be expressed as operating on a
> linear event-stream, instead of a nested tree model.  You can build
> the latter on top of the former, and event streams have a simpler
> object structure than tree-like models.  It might be safer to start
> with a parser/unparser API that runs on event streams, and then
> build node models (with cursors, pattern matching, etc.) on top
> later when the tools for those appear.  …Not that I’m longing
> to program an event-based API, but it’s better than nothing, and
> not lost effort either.

It's what the usual stream APIs do, at least what jackson and the json api from Java EE does.
The stream is just a tokenization of the text format
  [1, 3, { "foo": null } ] -> START_ARRAY NUMBER NUMBER START_OBJECT FIELD_NAME NULL END_OBJECT END_ARRAY

>From that you can construct an API like ASM when you call a method visit for each value token (NUMBER, STRING, NULL, TRUE, etc) and a method visit that ask for a sub visitor for START_ARRAY and START_OBJECT.

The next step, providing a tree/node API is harder and i think stupid mostly because JSON NUMBER is not typed so you have no idea if you should represent a number (as an int, a long, a float, a double, a BigInteger or a DigDecimal*, ??). You can introduce your own JsonNumber has an inline type but you will incompatible with any existing Java values. It's better to have a type representation that provide the type the user want for a number.

That why most APIs do not provide a generic tree API but a data binding API that takes a tree of types (a bean/record/interface tree) and a stream of JSON tokens and construct the corresponding Java representation (creating instances Bean/Record/Proxy). This tree of type can also be seen as a tokenization of the type informations (START_OBJECT_TYPE, START_ARRAY_TYPE, NUMBER_TYPE, etc).
Annotations on the tree of types are used to derive an adapter (or several with the concept of jackson views) to the visitor that will filter/map the field name and the value before creating the instances.

So IMO, a tree of instance of Valhalla inline types, a tree of nodes, is not useful but inline types can still be useful to simplify the visitor interface (instead of visitNumberInt/visitNumberLong/visitNumberDouble, etc, have a sole visitNumber(JsonNumber) with the inline type only existing on the stack to transfer the information from the reader to the deserializer (and vice-versa).

regards,
Rémi
* ECMA 404 doesn't define a size for the numbers !