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

[John Rose]

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.

> On Apr 16, 2020, at 8:53 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> And, of course, take full advantage of Valhalla when it’s there.
> 
>> On Apr 16, 2020, at 11:53 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> Also, a JSON parser should be designed so that, when the full pattern matching story is delivered, it works perfectly with pattern matching :)  This is a difficult constraint as it involves keeping all the possible directions for pattern matching in your head, and also designing something that can work now with the language we have and trivially migrate to the language we’ll have tomorrow.  This is no simple task!  
>> 
>>> On Apr 16, 2020, at 11:41 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>> Yes, go for it !
>>> 
>>> As far as i remember,
>>> - there was a human issue, why creating a JDK version when what you do is standardize the library "foo"
>>> - some technical challenges around providing a stream API, interoperable with java.util.stream or not.
>>> 
>>> Rémi
>>> 
>>> ----- Mail original -----
>>>> De: "Magnus Ihse Bursie" <magnus.ihse.bursie at oracle.com>
>>>> À: "discuss" <discuss at openjdk.java.net>
>>>> Envoyé: Jeudi 16 Avril 2020 17:02:45
>>>> Objet: Revival of JEP 198 (Light-Weight JSON API)?
>>> 
>>>> The recent removal of Nashorn has indicated several places were
>>>> javascript were used in the JDK mainly due to it's built-in support for
>>>> parsing JSON. While there exists several third party JSON libraries, the
>>>> lack of a JSON parser included in the JDK is becoming more and more
>>>> apparent. I guess it might be common for other users as well, to have
>>>> utilized Nashorn and Javascript for it's JSON abilities. Even if we now
>>>> deprive these users of Javascript, we need not deprive them of JSON
>>>> handling ability.
>>>> 
>>>> Fortunately, there already exists a JEP (JEP 198: Light-Weight JSON API)
>>>> [1] that proposes this. Unfortunately, to my knowledge, this is nowhere
>>>> closer to being delivered in the JDK than it was when it was created in
>>>> 2014.
>>>> 
>>>> It's 2020. I believe the inclusion of a standard JSON library in the JDK
>>>> is long overdue. This is not a technically challenging JEP. It's more a
>>>> question of "just doing it". Of course it's important to get the API
>>>> right, but once again, the problem space is small, and there are several
>>>> other successful JSON libraries out there that can serve as good
>>>> inspiration.
>>>> 
>>>> /Magnus
>>>> 
>>>> [1] https://openjdk.java.net/jeps/198
>> 
>