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

[Remi Forax]

----- Mail original -----
> De: "cay horstmann" <cay.horstmann at gmail.com>
> À: "discuss" <discuss at openjdk.java.net>
> Envoyé: Jeudi 23 Avril 2020 20:53:02
> Objet: Re: Revival of JEP 198 (Light-Weight JSON API)?

> 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

The problem is that at least Jackson can use BigInteger flawlessly, so it only works if you have Java at both ends or don't use JSON.stringify() but this is a use case that exist.

Said differently, the ECMA-404 which defines JSON is not a proper subset of ECMA-262 (3rd edition).

> 
> Cheers,
> 
> Cay

regards,
Rémi

> 
> 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 !