Class name handling for Collections.unmodifiableList changed in 2.9.4-SNAPSHOT

Similar to #1868 the handling of Collections.unmodifiableList has changed in a non-passive manner. The following test passes prior to jackson-databind 2.9.4-SNAPSHOT

@Test
public void serializeUnmodifiableList() throws Exception {
	ObjectMapper mapper = new ObjectMapper();
	mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY);

	String actualJson = mapper.writeValueAsString(Collections.unmodifiableList(Collections.emptyList()));
	assertEquals("[\"java.util.ArrayList\",[]]", actualJson);
}

However, it fails in jackson-databind 2.9.4-SNAPSHOT with the following error:

org.junit.ComparisonFailure: 
Expected :["java.util.ArrayList",[]]
Actual   :["java.util.Collections$UnmodifiableRandomAccessList",[]]

It could possibly be argued this is a bug that has been fixed. However, given the length of time this has been working this way I’d consider it a bug. This is compounded by the fact that in jackson-databind 2.9.4-SNAPSHOT the following fails:

@Test
public void derializeUnmodifiableList() throws Exception {
	ObjectMapper mapper = new ObjectMapper();
	mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL, JsonTypeInfo.As.PROPERTY);

	String actualJson = mapper.writeValueAsString(Collections.unmodifiableList(Collections.emptyList()));

	List<?> value = mapper.readValue(actualJson, List.class);
	assertTrue(value instanceof List);
}

with the following exception:

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `java.util.Collections$UnmodifiableRandomAccessList` (no Creators, like default construct, exist): no default no-arguments constructor found
 at [Source: (String)"["java.util.Collections$UnmodifiableRandomAccessList",[]]"; line: 1, column: 55]

	at com.fasterxml.jackson.databind.exc.InvalidDefinitionException.from(InvalidDefinitionException.java:67)
	at com.fasterxml.jackson.databind.DeserializationContext.reportBadDefinition(DeserializationContext.java:1451)
	at com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1027)
	at com.fasterxml.jackson.databind.deser.ValueInstantiator.createUsingDefault(ValueInstantiator.java:189)
	at com.fasterxml.jackson.databind.deser.std.StdValueInstantiator.createUsingDefault(StdValueInstantiator.java:267)
	at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.createDefaultInstance(CollectionDeserializer.java:255)
	at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:245)
	at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:27)
	at com.fasterxml.jackson.databind.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:116)
	at com.fasterxml.jackson.databind.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromArray(AsArrayTypeDeserializer.java:53)
	at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserializeWithType(CollectionDeserializer.java:314)
	at com.fasterxml.jackson.databind.deser.impl.TypeWrappedDeserializer.deserialize(TypeWrappedDeserializer.java:68)
	at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4001)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2992)

I think it would be ideal to revert jackson-databind 2.9.4-SNAPSHOT to serializing Collections.unmodifiableList in the same way it was prior to 2.9.4-SNAPSHOT

[aaronlangford31]

Hi, I’m looking into managing an upgrade from 2.8 to 2.10. I’m seeing some issues in backwards compatibility as a result of this issue (for example: 2.10 writes java.util.Arrays$ArrayList, 2.8 doesn’t know how to deserialize this). Any suggestions on how to make 2.10 write compatible types that 2.8 can read? Looking for something that can be done at the ObjectMapper level, rather than standardizing the way my code instantiates lists so that I get java.util.ArrayList.

[cowtowncoder]

@antenko I don’t know what is the situation here at this point. I’d suggest first trying the latest 2.9.x version, 2.9.10. And from that on, latest patches for 2.10(.5), 2.11(.4) and 2.12.2.

It is quite possible that there is no way to support combination of class-based polymorphic type deserialization for specialized JDK collection types: and specifically there is not necessarily goal of trying to preserve exact handling of an old version like 2.8.8.