Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to enable strict type parsing for jackson?

Jackson 1.9.9 is somewhat inconsistent in what it parses into scalar values (bool, int, string). Any array or object type fails but you can put any scalar type into a string. For bool 0 and not 0 are mapped to false/true. int attributes accept only numbers.

public class Foo { public String s; public boolean b; public int i; }

ObjectMapper mapper = new ObjectMapper();
System.out.println(mapper.readValue("{\"s\":\"abc\"}", Foo.class).s); // "abc"
System.out.println(mapper.readValue("{\"s\":true}", Foo.class).s); // "true"
System.out.println(mapper.readValue("{\"s\":123}", Foo.class).s); // "123"
System.out.println(mapper.readValue("{\"b\":123}", Foo.class).b); // true
System.out.println(mapper.readValue("{\"b\":0}", Foo.class).b); // false
System.out.println(mapper.readValue("{\"b\":\"abc\"}", Foo.class).b); // fails with JsonMappingException
System.out.println(mapper.readValue("{\"i\":\"abc\"}", Foo.class).i); // fails with JsonMappingException
System.out.println(mapper.readValue("{\"i\":true}", Foo.class).i); // fails with JsonMappingException
System.out.println(mapper.readValue("{\"s\":[]}", Foo.class).s); // fails with JsonMappingException
System.out.println(mapper.readValue("{\"s\":{}}", Foo.class).s); // fails  with JsonMappingException
System.out.println(mapper.readValue("{\"b\":[]}", Foo.class).b); // fails with JsonMappingException
System.out.println(mapper.readValue("{\"b\":{}}", Foo.class).b); // fails  with JsonMappingException
System.out.println(mapper.readValue("{\"i\":[]}", Foo.class).i); // fails with JsonMappingException
System.out.println(mapper.readValue("{\"i\":{}}", Foo.class).i); // fails  with JsonMappingException

Is there a strict mode for Jackson so that I get an error if someone passes for example a boolean value into a String attribute?

I am using this in a JAX-RS project and this makes error reporting based on exceptions thrown by Jackson somewhat difficult since I get most of the errors but not all of them. I would like to avoid getting a raw ObjectNode and checking everything manually. If a caller passes a boolean for a string then I would like to tell him that since this is most likely a programming error.

like image 848
magiconair Avatar asked Sep 22 '12 18:09

magiconair


People also ask

How do I ignore NULL values in JSON response Jackson?

You can ignore null fields at the class level by using @JsonInclude(Include. NON_NULL) to only include non-null fields, thus excluding any attribute whose value is null. You can also use the same annotation at the field level to instruct Jackson to ignore that field while converting Java object to json if it's null.

Does Jackson ignore unknown properties?

This time also it will work because Jackson is ignoring all unknown properties. That's all about how to ignore unknown properties while parsing JSON in Java using Jackson API.

How do I ignore a field in JSON response Jackson?

The Jackson @JsonIgnore annotation can be used to ignore a certain property or field of a Java object. The property can be ignored both when reading JSON into Java objects and when writing Java objects into JSON.


2 Answers

FWIW, if you come across this much later, like I did, ALLOW_COERCION_OF_SCALARS will help somewhat by reducing the number of conversions that Jackson will do you your behalf, although it's far from a complete strict mode; many type coercions will still be performed, but some will be prevented. The linked documentation gets into some of the details.

like image 115
Geoffrey Wiseman Avatar answered Oct 24 '22 20:10

Geoffrey Wiseman


Jackson data-binding has grown over time to accept more automatic coercions, and although there are some features (DeserializationConfig.Feature.FAIL_ON_NULL_FOR_PRIMITIVES) to enforce stricter checks, not many have been requested.

Given this, your best is to register custom JsonDeserializer for types you want to be stricter on, like boolean/Boolean. You can implement stricter checks there.

In addition, you can request feature(s) for stricter limitations: I think this does make sense for some use cases, esp. if looser conversions can hide real problems.

like image 43
StaxMan Avatar answered Oct 24 '22 18:10

StaxMan