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

[Cay Horstmann]

A JavaScript number is a double-precision floating-point number. JSON 
cannot currently serialize BigInt.

https://www.ecma-international.org/ecma-262/#sec-json.stringify
https://www.ecma-international.org/ecma-262/#sec-terms-and-definitions-number-value

Cheers,

Cay

Il 23/04/20 11:05, forax at univ-mlv.fr ha scritto:
> ----- 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 !
>