DeserializationFeature Feature Request - Strict Parsing for Primitives

[jojenki]

It would be nice to tell the mapper to only do strict parsing for the primitive types. This way, if I have the value 1 and want a boolean, it doesn't convert it to true.

For true primitives, e.g. boolean, int, long, it would have to throw an exception because null isn't valid. For "more complex" primitives, e.g. Boolean, Integer, String, it could return null, but that would be inconsistent.

Of course, one could always create custom deserializers, but it means that they must create one for each type, which seems a little unnecessary when they really just need a "catch-all" flag.

[cowtowncoder]

Would this not apply to wrapper types (Integer)?

There exists DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES, which covers the null case, for what it is worth. But the remaining thing would be to prevent coercions for primitive values.

One more aspect is that of numeric coercion: is it ok to coerce a floating-point number into integral value? Even if exact value is changed? Or perhaps only when truncation/rounding does not change the value (25.0 becomes 25).

[cowtowncoder]

FWIW, 2.6 adds DeserializationFeature.ACCEPT_FLOAT_AS_INT, disabling of which allows reporting error if a JSON floating-point value was being deserialized as int, long or BigInteger.
I realize that this does not implement the core of this request, but since I mentioned it earlier as another aspect, mentioning it for sake of completeness.

[Sarev0k]

I'd also like to see this feature.

I'd like to be able to have the JSON parser give back meaningful errors if the types used in the JSON input don't match the types used in by POJO, instead of Jackson blindly converting them to Strings for me.

Take the following as an example:

Given the following JSON:

{
    "string": 1
    "collection": [1, 3.4, false]
    "map": {
        "string": 3
    }
}

And the following POJO:

class MyClass {
    String string;
    List<String> collection;
    Map<String, String> map;
}

To get the type of errors I want, I'd must implement the following three deserializers:

1. JsonDeserializer<String>
2. JsonDeserializer<Collection<String>>
3. JsonDeserializer<Map<String, String>>

Having a single toggle to disable automatic type marshaling of primitives to strings would be extremely helpful in solving this problem.

[cowtowncoder]

@Sarev0k On deserializers: all you have to implement is JsonDeserializer<String>. Collection, Map and all structure type deserializers will delegate to appropriate element deserializer, recursively; and know how to use custom deserializer instead of standard one.
You may also override element deserializer on per-property basis with @JsonDeserialize(contentUsing=MyStringDeserializer.class).

So: no, do not override default Collection, List or Map deserializers if you only need to modify handling of contained types.

Majority of users vastly prefers coercion because of all kinds of weird languages, clients, libraries that seem unable to produce properly typed content. Jackson actually started with much more rigid model, where most cases did result in exception.

But I think it is good to be able to configure things to choose between strict/loose, at appropriate granularity. The main complexity really comes from vast number of types supported.

[Sarev0k]

You're right. Looks like I messed something up. This should be good enough for my purposes.

[omervk]

+1 to this issue. I was just caught by surprise by this behavior. Any idea when this might be fixed?

[cowtowncoder]

I don't think anyone is working on this; I haven't, and there is a huge backlog of possible things to work on. So the best chance here would definitely be a PR.

[cowtowncoder]

I think this should now be covered by #1106 (and DeserializationFeature.FAIL_ON_NULL_FOR_PRIMITIVES); closing this one since explanation for that one is more precise, and explains other relevant functionality.