Consider inviting Gson and Jackson to a discussion about a (really) standard API

Json-B and Json-P were initially seen as a very welcome initiative, finally bringing some standardization to json parsing and writing.

Let’s face it: it is not a huge success, so far. Jackson and Gson, to name just two, are hugely popular, and small but annoying discrepancies between Jackon, Gson, and JSON-P/B (in handling null values, in approach and vocabulary) exist as before.

I suspect (but I admit I have not read blogs about this matter so I may have missed crucial points in the debate) that this may have been initially related to the JSR process being notoriously not oriented towards neutral discussion about adopting the best specification (see Apache’s position, or Doug Lea’s opinion).

Now that this spec is lead by Eclipse, I think there is hope that this may change.

I see that a version 2 of the API is underway. But I fear it will not suffice to bridge the gap and make this a really effective standard in the Java-Json world.

It seems to me that discussions are sometimes stuck because of too much sticking to the original design; or just because not enough voices and points of view are expressed in the debate. I am pretty sure that voices from experts from Jackson and Gson, to name just two, would lead to a much better, and hopefully really standard, API design. (This is *not* meant to suggest that JSON-B is bad as it is currently, but just to suggest that more ideas could lead to a better design, combining the strengths and good ideas of JSON-B with the strengths and good ideas of other library designers.)

To take just one example, I have tried to [discuss](https://github.com/eclipse-ee4j/jsonb-api/issues/108) the “closeable” issue of the Json-B current API, which I find hugely unsatisfactory. I have been told that closing is necessary, for a reason I did not manage to understand. (And I do not consider myself a beginner in Java.) Jackson and Gson both manage to reach good performance and no particular problem (as far as their popularity can testify) without requiring their users to close serializers, in many cases. This is only one example, but it makes the API much more pleasant to use and should be a source of inspiration.

Would you consider inviting these experts, and possibly others of course, to an open-minded discussion about a new version of the API that would aim at becoming an effective standard with multiple implementations? It may be too late for Json-B API version 2. But in that case, please consider this possibility for a future API version 3.

Start by reviewing the proposal and the linked JSON-B issue #108, then examine the concerns about Json-B, Json-P, Jackson, and Gson interoperability described here. Done would require a decided path for involving external experts and shaping a future standard API; no implementation files or tests are named.

Written by the indexing model from the issue text.