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

[Brian Goetz]

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