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

[oliviercailloux]

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 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.

[rmannibucau]

@oliviercailloux few comments to try to refine this topic:

1. IMHO it is not the right moment "just now", javax -> jakarta migration is a huge mess (look for example how microprofile just does not work anymore with jakarta) so it can be worth waiting for jakarta to be mainstream otherwise work can be frustrating and if projects adopt it, users can not be able to migrate.
2. about the close (happy to discuss it more interactively with you on slack, IRC or another channel): it more or les the same with jackson and Gson as well ;). One difference though is that it has less features so let the user wrap this area himself and therefore move the close handling in user land. However note that part of the good perfs are due to buffer recycling and jackson uses thread local there which can create leaks and prevent any cleanup when allocation requires it (native mem or max allocation size) - personally I consider this by itself justifies the close presence which enables to get the same perf without this bug. However, the more obvious reason to have a close is that jsonb loads itself CDI components/bean instances for the lifecycle of the jsonb instance and generally speaking (there are cases it is not true), a CDI bean must be released when no more needed (close) to release the bean stack/dependencies (you have the same with spring when not using only request/session/singleton scopes). In other words, you have the exact same issue if you plug in jackson a custom lookup for (de)deserializers, generally there are hacks to release properly the instances but there is not hundreds of solutions theres I think.

So overall I fully agree more people should be involved - but note that they are welcomed there. The very small warning is just about the timing and the jakarta point which can delay the impact of any contribution a little bit.

Hope it makes sense.

[aguibert]

hi @oliviercailloux, I agree that inviting Jackson/Gson would be a great addition to JSON-B, and is something I considered when first joining the JSON-B group.

I've reached out the maintainer of Jackson via Twitter to see if he is interested in collaborating on this, so we'll see what happens.

[oliviercailloux]

so we'll see what happens

Has anything happened? What about Gson?