Introducing JSON-B with Spring Boot 2.0

JSON Binding (JSON-B) is the new Java EE specification for converting JSON messages to Java Objects and back. JSON is used everywhere and so far we had two main ways of dealing with JSON conversion in Java- using either Jackson or GSON. With the introduction of JSON-B, we have a standard way of handling this conversion. In this article, we will see how Spring Boot 2.0 supports JSON-B, how easy it is to use it and how does it compare with the other options.

And you need to choose the preffered-json-mapper setting to make sure that JSON-B is chosen. You may get GSON or Jackson on the classpath and then you can’t be sure how the autoconfiguration will work without this setting:

spring.http.converters.preferred-json-mapper=jsonb

With that in place, we are going to write a simple Rest Controller and a simple Car Class, that will make use of the JSON-B conversion:

It is worth noting a few things. Treatment of the Calendar is specific to JSON-B specification and so is the simple disappearing of the missing Optional. I think the treatment of these two concepts is quite clean here.

I showed you these three different examples to really make a point here. There is a lot of value from an official standard that deals with converting Java to JSON. Of course, JavaEE championed standards were not always successful. The original EJBs were mostly a disaster (sorry if you liked them, but sadly they did not catch on). CDI beans were much better (although they did not get enough traction in my opinion). JPA was on the other hand very successful and it is still very popular.

I strongly believe that the JSR 367 (this is Java Specification Requests for JSON-B) is here to stay and will bring a lot of good to the JVM ecosystem. I think we all want a more united and more seamless JSON development experience in the Java world.

We will see now how these different libraries deal with JSON to Java conversion.

Converting JSON to Java Objects

It is important for a converter to be able to convert both ways between Java Object and JSON without changing the object itself. With the new standard, I wanted to see how well it handles this task.

We will use the original Car Object, get the JSON from JSON-B, GSON, and Jackson and then feed it back with a POST to see how the recreated Object looks like. We will check the equality to the Original Object and inspect any potential changes in the payload when returned once again.

Conversion with JSON-B

JSON-B passes the simple test of returning the same JSON text that it is sent.

JSON-B fails the equality check! It turns out that JSON-B assigns a naked null rather than the Optional value to the field when it is not present in the JSON! This is very disappointing, as it may cause unexpected bugs. To be clear what happens is:

JSON-B deals with Optional.empty() by not including it in the JSON response.

When JSON parsed into Java Object does not have a value for an Optional<> field it assings it null rather than Optional.empty()

This breaks the idea of Optional

This is disappointing enough that I hope it will change in the future iterations of the standard.

Conversion with GSON

GSON passes the simple test of returning the same JSON text that it is sent.

GSON also passes the equality check! It correctly deals with the Optional and the Calendar cases.

Conversion with JACKSON

Jackson passes the simple test of returning the same JSON text that it is sent.

Jackson fails the equality check! While Jackson is correctly handling the Optional case it fails to deal with the Calendar correctly. It loses the Zone information (in my case London/Europe) and changes it to UTC. This simplification can cause unexpected bugs in different systems.

Conclusion

I believe that JSON-B is a great idea for a new standard. JSON became so important that having Java community agree on a good way of dealing with it can be very helpful.

It is apparent that dealing with JSON to Java and back is not as trivial as it may seem. As demonstrated here, these conversions may end up causing some unexpected side effects. Personally, I would like JSON-B to be more like GSON- perhaps sacrifice human readability for a clear back to back conversion.

No matter which converter you chose, Spring Boot 2.0 makes it easy to use. I am looking forward to JSON-B entering the field as the third worthy contender for your JSON converter of choice.

Even if they are not meant to be attributes parameter by design, they can still be used in that fashion and JSON libraries need some way of dealing with that. Good point though- if you don’t use it, you are not exposed to the risk.

I think the JSON to Java part fails to deal with Optional here, as it is not using a constructor and only manually mapping attributes (not being too smart). With this approach, it seems that Jackson and GSON way of dealing with it is simpler.

1) JSON-B is not “the new Java EE standard” — it is simply a specification that is included in Java EE. Java EE is a collection of specifications implemented as a platform. Well, saying that JSON-B is ” the new Java EE standard” is not wrong in itself but in this context (this tutorial is about Spring Boot), the distinction between Java EE and Spring is not clear. I would rephrase it, you can’t imagine how high is the general Java EE/Spring confusion.

Just say that “JSON-B is the new Java API for JSON Binding (JSR-367)” and in the end of the article, if you wish, you can specify: “if you are using JavaEE instead of Spring, JSON-B is supported by default in Java EE 8”.

2) “JSON is used everywhere and so far we had two main ways of dealing with JSON conversion in Java- using either Jackson or GSON.” — this phrase is not entirely correct. JSON-B is a new specification, indeed, for *binding* objects. But we had JSON-P (you know, javax.json.JsonObject) since a long time ago.

3) Why are you including as dependency the following:

org.glassfish
javax.json
1.1

That is the implementation of JSON-P, yet you did not include the JSON-P api. Is it needed somehow for Yasson to work? Does Yasson include the JSON-P api? I am not sure. Either way, you should clarify this JSON-B/JSON-P topic.

1) I edited the sentence to say specification rather than standard. I think it adds clarity.
2) I see where you are coming from. Maybe I could improve the phrasing to be more precise here.
3) The official JSON-B page claims that you need that dependency. I could see if it works without, but I just followed their documentation here. Could be not needed though.

Interesting blog post about POJOs! I personally think POJOs have their place (interacting with some 3rd party APIs), but I agree that anaemic data models are often the wrong way to build your system.

Post navigation

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy

About

E4developer is a place where I share my open and honest views on software development, technology and working with people. The name – e4 comes from a chess move, this is how I start most of my games. Follow me on twitter – @e4developer