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

[John Rose]

On Apr 23, 2020, at 11:05 AM, 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