JsonDeserialize(contentAs=...) broken with raw collections

[cpopp]

JsonDeserialize(contentAs=...) doesn't seem to be honored if used with raw collections.

In the following example I would expect that the items field would be deserialized as the MyItem class but instead comes out as a java.util.LinkedHashMap. Adjusting the following example from List to List<Object> causes things to work as expected. (I tried it in 2.9.10 and 2.10.1)

public static class MyCollection {
	@JsonDeserialize(contentAs = MyItem.class)
	public List items;
}

public static class MyItem {
	public String name;
}

public static void main(String[] args) throws Exception {
	ObjectMapper objectMapper = new ObjectMapper();
	
	MyCollection myCollection = 
			objectMapper.readValue("{\"items\": [{\"name\":\"item1\"}]}", MyCollection.class);
	
	System.out.println(myCollection.items);
	System.out.println(myCollection.items.get(0).getClass());
}

[{name=item1}]
class java.util.LinkedHashMap

I initially encountered this while doing some dynamic class creation via a refineDeserializationType method in a custom AnnotationIntrospector which caused the type from the subclass to be lost.

[cowtowncoder]

Interesting... thank you for reporting this, I think it should work as expected so need to see what causes the issue.
Problem does not occur with List<?> either. I wonder if this is due to some optimization in TypeFactory...

[cowtowncoder]

Ok, yes, content type is lost within TypeFactory.constructSpecializedType() somehow; difference being that raw List apparently has no type bindings (does not come from generic type).
Need to figure out how to fix: probably affects raw Map, Collection and Set too.

[cowtowncoder]

Found an easy fix: changing order of checks to first handle collections, then skip non-generic types seems to work, at least for Map/Collection use cases.

[eduizquierdo]

@cowtowncoder, I'm hitting same issue but don't understand your solution, maybe because I'm new to jackson. Can you be more explicit or provide a code sample?

[cowtowncoder]

@eduizquierdo There is a fix in Jackson 2.10.2 that should handle the original case. 2.10.2 was just relesed and is available for upgrade.
So no workarounds needed: just use the annotation as suggested, but make sure to use 2.10.2 not an older version.