`TypeFactory` cannot convert `Collection` sub-type without type parameters to canonical form and back

[lbilger]

Describe the bug
When constructing a type using constructType and getting its canonical String representation, a type parameter is added to classes that implement a Collection type, even if the class itself does not have any type parameters. Trying to read the result back using constructFromCanonical fails with java.lang.IllegalArgumentException: Cannot create TypeBindings for class kotlin.collections.EmptyList with 1 type parameter: class expects 0.

Version information
Tested with 2.11.4 and 2.12.2.

To Reproduce

See the following test written in Kotlin:

class JacksonTypeFactoryTest {
    private val objectMapper = ObjectMapper()

    @Test
    fun `EmptyList type can be converted to canonical string and back`() {
        val canonical = objectMapper.typeFactory.constructType(emptyList<String>().javaClass).toCanonical()
        println(canonical)
        val type = objectMapper.typeFactory.constructFromCanonical(canonical)
        println(type)
    }

    @Test
    fun `StringList type can be converted to canonical string and back`() {
        val canonical = objectMapper.typeFactory.constructType(StringList::class.java).toCanonical()
        println(canonical)
        val type = objectMapper.typeFactory.constructFromCanonical(canonical)
        println(type)
    }

    @Test
    fun `Non-collection type can be converted to canonical string and back`() {
        val canonical = objectMapper.typeFactory.constructType(ConcreteType::class.java).toCanonical()
        println(canonical)
        val type = objectMapper.typeFactory.constructFromCanonical(canonical)
        println(type)
    }

    class StringList : ArrayList<String>()

    open class ParamType<T>

    class ConcreteType : ParamType<Int>()
}

The first two tests fail, while the third one succeeds. So it seems to be a problem only with types that extend Collection.

Expected behavior
TypeFactory should always produce canonical type names that it can parse again.

Additional context
Although this doesn't seem to be a Kotlin-specific problem, it gains relevance by the fact that Kotlin uses the EmptyList class to optimize empty lists.

This is similar to #1415 but different in that I'm not using constructCollectionType here.

[cowtowncoder]

Assuming this is not Kotlin-specific, it'd be great to be able to reproduce with plain Java, to add test here (tests that use Kotlin would need to go under Kotlin module).
Seems like tests 2 and 3 would be easy to convert.

[lbilger]

Thanks for the fast answer! Following is the test converted to Java. The first one would only work if you have the Kotlin libs on the class path, but you can just remove it.

public class JacksonTypeFactoryTest {
    private final ObjectMapper objectMapper = new ObjectMapper();

    @Test
    public void empty_list() {
        String canonical = objectMapper.getTypeFactory().constructType(CollectionsKt.<String>emptyList().getClass()).toCanonical();
        System.out.println(canonical);
        JavaType type = objectMapper.getTypeFactory().constructFromCanonical(canonical);
        System.out.println(type);
    }

    @Test
    public void string_list() {
        String canonical = objectMapper.getTypeFactory().constructType(StringList.class).toCanonical();
        System.out.println(canonical);
        JavaType type = objectMapper.getTypeFactory().constructFromCanonical(canonical);
        System.out.println(type);
    }

    @Test
    public void non_collection() {
        String canonical = objectMapper.getTypeFactory().constructType(ConcreteType.class).toCanonical();
        System.out.println(canonical);
        JavaType type = objectMapper.getTypeFactory().constructFromCanonical(canonical);
        System.out.println(type);
    }

    static class StringList extends ArrayList<String> {}

    static class ParamType<T> {}

    static class ConcreteType extends ParamType<Integer> {}
}

[cowtowncoder]

Thanks! It seems likely that addressing problems shown by 2 Java-only cases might handle Kotlin case too.

[cowtowncoder]

I can reproduce this. Yeah, this will be very difficult to resolve... I'll see what I can do, but I would recommend that no code outside of Jackson core functionality tries to use canonical name for JavaType at all; handling is bit too specialized for the limited use case of Jackson itself. Whereas java-classmate would (for example) properly bind type parameters to actual type, Jackson's Collection-/Map(Like)Type are more interested in type-bindings of key/content value types.