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