Deserialize array with nulls

[dstroyrofworlds]

Deserializing an array with a null element will result in the ImmutableList throwing a nullpointer.

Is there a setting to ignore nulls, is this the expected behaviour or can the library be updated to ignore nulls based on a setting ?

Or should ignoring the nulls be default behaviour ?

[cowtowncoder]

What would be needed is test case to show what happens. Description only helps up to certain point.
But as long as nulls are allowed within ImmutabeList they should be added as is I think.
I don't think quiet ignoral of nulls as default behavior makes sense since it would be quite non-obvious transformation.

But there are plans for generally configurable handling of nulls for Jackson 2.9:

FasterXML/jackson-databind#1402

which could eventually allow ignoral (using SKIP for "content nulls").

[keisar]

I've also encountered this, since ImmutableList doesn't allow nulls, should GuavaCollectionDeserializer handle nulls as a special case ? maybe implement getNullValue ?
Currently if my deserializer returns null GuavaCollectionDeserializer will try to add that to the ImmutableList (through the builder) and that in turn throws an exception.
I can supply a test case if this is something that should be fixed and I'll be happy to contribute a fix, just wanted to get some input on this before I try to

[cowtowncoder]

This issue should be re-created at:

https://github.com/FasterXML/jackson-datatypes-collections/issues

since this repo is deprecated (single repo is easier for releasing new versions, so somewhat related modules are lumped under one undrella repo).

As to solution: implementing getNullValue() will not help, alas, as that refers to null value of type (ImmutableList here), and not for elements. Call to getNullValue() will be made, but for element values, which have no idea where they are added.
It is now (with 2.9.0) possible to use @JsonSetter(contentNulls=Nulls.SKIP) (or, Nulls.AS_EMPTY), and this can even be configured as type defaults for ImmutableList I think. But I would not be against trying to support this for for specialized Collections either -- although I do dislike Google engineers insistence on changing contracts and waging war on nulls. If they implement Collection, it'd seem reasonable to follow contract not add their own extreme ideology on top of it.

But as to what could be done... I am not really happy with simply dropping nulls (it is throwing away data that is there for some reason), but perhaps one could configure one of Nulls behavior as default? To me Nulls.AS_EMPTY seems perhaps best guess -- it'll work for, say, Strings (giving ""), fail for others. And if users prefer, they could use SKIP or FAIL. I guess I could also go with default of FAIL, to at least give bit better error message.