Jackson @JsonView for serialising and deserialising object

Neha Kumari
3 min readSep 28, 2017

--

Let me put a little about serialisation and its need first. Serialisation is flattening of object to data stream and deserialisation is vice-versa. We primarily need it to send our data(object) over network(e.g. server-client interaction) or store it in file, and because the network infra and hard disk understand bits and not objects we need to convert our data into a suitable form.

Most famous java serialiser/deserialiser are jackson and gson, they get compared very often. And we have our own choice of choosing one over the other as per the need of the hour. If we compare on the basis of performance aspect, for small/medium sized list gson is preferred, while for large list Jackson provides a better response. Also gson provides simplicity of toJson/fromJson in simple cases, where as Jackson provides extensive annotation support and is built into all JAX-RS and spring framework. Both are open source and the source code can be found here :

Jackson Annotation : It provides a very simple way to perform customised serialisation.

  1. Jackson Serialisation Annotations
  2. Jackson Deserialisation Annotations
  3. Jackson Property Inclusion Annotations
  4. Jackson Polymorphic Type Handling Annotations
  5. Jackson General Annotations

For now I will mainly focus on the @JsonView annotation which comes under Jackson General Annotations, as it is not much discussed over the internet and provides some useful customisation on serialisation.

@JsonView is used to indicate the View in which the field will be included while serialisation/deserialisation and is very helpful when it is needed to include different fields of object while serialisation for different use cases. @JsonView annotation is supported on Spring for v≥4.1

One special case can happens in which @JsonView is used to exclude one particular view while serialisation. To tackle this situation define default view for all of the field which does not has a view and then make DefaultClass by implementing all the interfaces except the one which is to be excluded. It can be easily visualised via an example.

public class VehicleInfo {

@JsonView(VehicleInfoViews.TrainInfoViews.class)
private String frequency;

@JsonView(VehicleInfoViews.BikeInfoViews.class)
private String silencerType;

@JsonView(VehicleInfoViews.CarInfoViews.class)
private Integer noOfSeats ;

@JsonView(VehicleInfoViews.BikeInfoViews.class)
private String gearType;
@JsonView(VehicleInfoViews.Default.class)
private String horn;
@JsonIgnore
public String fetchJSON() {
return new ObjectMapper().writeValueAsString(this);
}

@JsonIgnore
public String fetchJSON(Class viewClass) {
return new ObjectMapper().writeValueAsString(this, viewClass);
}
}

And views can be defined like :

public class VehicleInfoViews {

public static interface TrainInfoViews {}
public static interface BikeInfoViews {}
public static interface CarInfoViews {}
public static interface Default {}

public static class TrainInfoClass implements TrainInfoViews {}
public static class BikeInfoClass implements BikeInfoViews {}
public static class CarInfoClass implements CarInfoViews {}
public static class DefaultClass implements TrainInfoViews,
CarInfoViews{},
Default {}
}

Note that DefaultClass does not implement BikeInfoViews. Now it can be serialised using the “DefaultClass” view. And the serialised string should not contain the fields which was using BikeInfoViews. It can be tested as follows :

VehicleInfo vehicleInfo = VehicleInfo.builder().frequency("f1").silencerType("sT").noOfSeats(2).gearType("rock").horn("beep").build();String serializedValue = vehicleInfo.fetchJSON(VehicleInfoViews.DefaultClass.class);
assertFalse(serializedValue.contains("gearType")); assertFalse(serializedValue.contains("silencerType"));
// to Deserialise :
VehicleInfo vehicleInfo = new ObjectMapper().readValue(serializedValue, VehicleInfo.class);

@JsonView provides an easy way to filter fields depending on the context of serialisation.

As a developer I feel these libraries make our lives easy, but there are certain things which makes our lives miserable also, e.g. non-testability of PIG script. In my coming post, I will be covering PIG scripting, and how to extend its testability.

--

--