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

Remi Forax forax at univ-mlv.fr
Thu Apr 16 15:41:55 UTC 2020


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


More information about the discuss mailing list