Johnzon and JSON-P/JSON-B status

Apache Johnzon provides a set of modules around Java and JSON. Most famous ones are its JSON-P implementation (a.k.a. johnzon-core) and its JSON-B implementation (a.k.a. johnzon-jsonb) which is built on top of the pre-JSON-B Johnzon mapper (a.k.a. johnzon-mapper).

Since it implements the two official JavaEE/JakartaEE specification, as an user, you can wonder what is the status regarding the specification of this implementation. This is particularly important for end users since it kind of guarantees them their implementation respects the "contract" and portability they can expect from such a standard. It also guarantees you will be able to run on multiple implementations (servers) and/or change the implementation if you encounter any issue with one and therefore keep your delivery velocity high.

Before giving you the status, it is important to understand what the compliance means for such an implementation.

A specification is composed of the following items:

• The specification document (generally a PDF) which describes what an implementation must respect,
• The API jar(s) - without any implementation inside except the provider loading for good specifications,
• The javadoc of the API,
• A set of test (called Test Compatibility Kit or T.C.K.) which tests all the point of the specification document/javadoc and therefore ensures any implementation passing these tests that it is compliant.

Johnzon 1.1.x was almost compliant but not fully. Without entering into the details here are the main differences:

• Number formatting support was partial (@JsonbNumberFormat),
• Date formatting was not 100% correct regarding spec expectations - mainly on some advanced cases and zone formatting,
• EnumMap/EnumSet are fully supported whereas the TCK was ensuring it was not deserializable - will be fixed in the TCK since the specification must enable it,
• The specification had some weird wording about numbers not exactly matching IEEE754 representation which should be represented as string instead of numbers (goal was big number support but with such representation even 0.1 should be represented as a string). TCK will be dropped from next specifications and implementations can exclude the related tests since they don't match anything usable,
• For JSON-P it was mainly the 1.1 stream methods added to JsonParser which were not fully compliant and the link between JSON-P implementations (parsers, readers, generators, wrtiers) and the underlying IO was not 1-1 so considered not compliant (for instance, Johnzon was closing as soon as possible the underlying IO for a reader whereas the specification expects that reader.close() is called to do that).

The good news is that in Johnzon 1.2.0 all the compatibility work had been done and next Johnzon release will be fully specification compliant.

In terms of user impacts it mainly means that, without any customization, the date serializations will be slightly diffrent everything else not being visible if the API usage was respected (if you forgot to close a JsonReader, Johnzon likely did for you in 1.1 but in 1.2 it will not leading to a potential leak, however you must always close a reader so this is not considered as a regression from the API point of view for example).

This kind of change has direct impacts on containers integrating this implementation for JSON-P and JSON-B like Apache Meecrowave (which now has a fully compliant stack for Microprofile, yeah!) and Apache TomEE.

Finally, I'd like to mention two important things which are key for the Java ecosystem and communities here:

• All that work and refinements were only possible due to the open sourcing of the TCK and moregenerally JavaEE so thanks Oracle and Eclipse to have made it possible.
• The challenges on the TCK (the big number and EnumSet/Map support) were confirmed by Yasson team which is the reference implementation for the specification. From outside, it can look like concurrent implementations are "fighting" but actually from the inside, it is rather a positive competition and even sometimes, like there, a convergence.

So thanks Java people to be that pro and constructive and long live to JakataEE!