Embed Apache Johnzon in your library to not depend on a dependency

Sometimes you need to parse JSON files in a library. Then the question is pretty quickly: do I use a SPI (Service Provider Interface) to let the user choose the library he uses with my code or do I bind my library to one parser/writer?

Sometimes the answer is easy: when the need is basic (read/write) having a SPI and a default implementation is pretty good and let your users avoid to depend on one implementation. Said otherwise, you let your users reuse the implementation they probably already have in their application/classpath.

However sometimes you need a more advanced setup to get some customizations or features (like comments in JSON for instance which is very handy for configuration files) so either you bind your library to one implementation and your users end with N JSON implementations they don’t control and which potentially conflict together, or you enhance a lot your SPI risking to loose some features if your user chooses an implementation not supporting some of your needs, or you can also grab an implementation which work fine for you and just put it in your delivery. This last option is pretty nice cause then your code can use all the shortcuts an implementation can offer – like custom annotations.

Going further with this last option you can also potentially reuse some standard API like JSON-P or the coming JSON-B in your code and just hide it and not depend on the container for the runtime.

Of course there is no free lunch and it will make your delivery a bit more heavy but a good mapper is ~200k max so it is still a good option for JSON needs.

How to do it?

Prettify JSON in 4 lines with JSON-P

JSon Processing API was a great step for standardization of JSON in Java world and its API is surprisingly smooth to prettify a JSon payload.

Apache Johnzon JSON library and Javascript date

By default Apache Johnzon JSON-Java mapper uses the pattern “yyyyMMddHHmmssZ” for Dates. The good thing about this pattern is that it is fast enough for most cases. However, its drawback is not as common as the ISO8601 format of the RFC822.

The solution is quite simple.

OpenJPA and Date JSON serialization

Following the trends, you can try to push your entities to the front layer of your application without any in between conversion. A common sample is to return an entity in a JAX-RS bean.

For instance:

JSON and WebSocket: Johnzon to the rescue

When writing a WebSocket endpoint the first thing you do is to create the endpoint (connection point) then you have to define the protocol to use. Because of what is modern IT world it is quite common to use JSon as payload format for WebSocket messages. Of course you can use any JSon mapper you want or JSON-P directly but you can actually go a bit further and that is what does Johnzon in its coming 0.8-incubating release.

JSon for configuration: Apache Johnzon made another step with comments

Using JSon for a configuration file is very tempting but there is a big drawback: you can’t comment anything with a strict JSon parser.

This is something which is blocking for a configuration IMO because you often need to explain why you configured something in the way it is.

Json API (JavaEE 7) + Java 8: collection to JsonArray

JavaEE 7 brings an API for JSON arrays (the surprising JsonArray ;)), Java 8 brings a stream API and lambdas so now you can combine both to create a JsonArray from a Collection!

Json Processing specification implementation: Apache enters the game

JSR 353 is part of JavaEE 7 and until today mainly glassfish implementation was available (found also https://github.com/vvakame/jpp-jsr353-impl on github). Since Apache will need its implementation (TomEE and CXF for instance ;)) and since JSon is a very common need at Apache, creating an incubator project for it didn’t create a big debate.

s/tomee.xml/tomee.json/

TomEE uses conf/tomee.xml as main configuration but we are at the moment thinking to an alternative configuration based on JSON.