NPE with CollectionDeserializer with TreeSet class, with input null

[reinaldo-besen]

Hello,

I've a problem while trying deserialize a TreeSet with a custom deserializer, in my situation deserializer not find the registry to add the collection, and returns null, but as TreeSet does not accept nulls, pops exception in Java, as below:

com.fasterxml.jackson.databind.JsonMappingException: (was java.lang.NullPointerException) (through reference chain: com.framework.entity.dynamic.DocumentEntityInfo["folders"]->java.util.TreeSet[0])
    at com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:378)
    at com.fasterxml.jackson.databind.JsonMappingException.wrapWithPath(JsonMappingException.java:350)
    at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:298)
    at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:249)
    at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:26)
    at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:490)
    at com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:95)
    at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:260)
    at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeOther(BeanDeserializer.java:163)
    at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:135)
    at com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer._deserializeTypedForId(AsPropertyTypeDeserializer.java:120)
    at com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer.deserializeTypedFromObject(AsPropertyTypeDeserializer.java:91)
    at com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer.deserializeTypedFromAny(AsPropertyTypeDeserializer.java:163)
    at com.fasterxml.jackson.databind.deser.impl.TypeWrappedDeserializer.deserialize(TypeWrappedDeserializer.java:42)
    at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3807)
    at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2797)
Caused by: java.lang.NullPointerException
    at java.util.TreeMap.compare(TreeMap.java:1290)
    at java.util.TreeMap.put(TreeMap.java:538)
    at java.util.TreeSet.add(TreeSet.java:255)
    at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:284)

The suggestion is to treat null for this situation in the Collection Deserializer, and not add the item in the list in return. Line 284 of CollectionDeserializer class.

https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/deser/std/CollectionDeserializer.java

I've searched for an issue linked to that, without success in the issue tracker.

Thanks for your help.

[cowtowncoder]

I don't like the idea of magic null suppression, especially as this would only be relevant for tree-based Collections. But I am open to ideas for improvements.

One thing that may help is work I am planning for 2.9 that does allow annotation-based (and type-defaults too) configurable handling of incoming nulls, including option of skipping them.
But I think I'll need to keep in mind the case of null contents (elements), not just value itself, since the two are separate (if related) concerns.

[reinaldo-besen]

My simple suggestion is to create a parameter in DeserializationFeature class, to allow the supression of the null value in the collections in this way is a developer to define what best suits your situation.

[cowtowncoder]

Actually while I do not like one-off feature for null handling for just collections, I think it would be valid to block null from TreeSet, given that it can not work with JDK.

[cowtowncoder]

For what it's worth, #1402 will add a way to address this in general fashion. Leaving this open for now until it gets implemented.

[cowtowncoder]

Actually closing as it should be handled via #1402, and I have no plans for type-specific hack.