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

[forax at univ-mlv.fr]

I've been mulling an implementation since this email 
here is my take 
https://github.com/forax/jsonapi 

Rémi 

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

> On Apr 23, 2020, at 11:05 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

>> 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).

> Yep. A Lisp refugee like me will immediately think “S-expressions
> are enough; why use anything else” and that me to look for some
> sort of clunky prefab node structure. The more modern side of me
> will look for a mapping or transcoding to/from the event stream
> and whatever AST or other data I choose to work with at the moment.

> My point here is that the event stream “layer” of the library is
> a safe-ish first step, even if it fails to use value types in the clever
> way you suggest. The next layer up will surely be data binding,
> and maybe a prefab tree for folks like me. IMO, the upper layers
> will want to work well (IMO) with *both* mutable vs. immutable
> (easy to edit vs. safe) AST representations, just as ju.List supplies
> both options, and will also want to perform more ad hoc transcodings
> (not just standard ASTs) to both mutable and immutable objects.
> The immutable objects are likely to be inline objects, sometimes.
> (For that matter, inlines can also express logically mutable objects.)
> The longer we delay nailing down the transcoding layer, the more
> future features of the language we can use to make that layer more
> flexible and powerful.

> — John