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

[Laurence Cable]

On 4/23/20 10:50 PM, Cay Horstmann wrote:
> 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.
+1!
>
> 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.
+1
>
> 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 !