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

[Cay Horstmann]

I see...and people want to use this to serialize monetary values as 
"number". See 
https://stackoverflow.com/questions/11319445/java-to-jackson-json-serialization-money-fields 
and https://github.com/zalando/jackson-datatype-money. That seems like a 
terrible idea, but whatever.

But why is that problematic for a tree API? The tree node needs to hold 
the string of digits (and sign etc.) since that's what an ECMA-404 
"number" is. It's up to the user of the API to interpret the string as a 
double, BigDecimal, or String.

Cheers,

Cay

Il 23/04/20 13:18, Remi Forax ha scritto:
> ----- 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 !