Failure to resolve generic type parameters on serialization

(note: originally reported against Kotlin module, example in Kotlin but failure in databind, transferred)

I have a Either definition:

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME)
@JsonSubTypes(
    JsonSubTypes.Type(Either.Left::class, name = "left"),
    JsonSubTypes.Type(Either.Right::class, name = "right")
)
sealed class Either<out A, out B> {
    class Left<A>(val value: A): Either<A, Nothing>()
    class Right<B>(val value: B): Either<Nothing, B>()
}

that I use in a simple data class:

data class Foo(
    val bar: Either<String, String>,
    val second: String
)

I create an instance and try to serialize:

return Foo(
    bar = Either.Left("aaa"),
    second = "bbbb"
)

but jackson throws an IndexOutOfBoundsException:

Caused by: java.lang.IndexOutOfBoundsException: Index: 0
        at java.base/java.util.Collections$EmptyList.get(Collections.java:4481)
        at com.fasterxml.jackson.databind.type.TypeFactory._resolveTypePlaceholders(TypeFactory.java:478)
        at com.fasterxml.jackson.databind.type.TypeFactory._bindingsForSubtype(TypeFactory.java:451)
        at com.fasterxml.jackson.databind.type.TypeFactory.constructSpecializedType(TypeFactory.java:423)
        at com.fasterxml.jackson.databind.cfg.MapperConfig.constructSpecializedType(MapperConfig.java:305)
        at com.fasterxml.jackson.databind.DatabindContext.constructSpecializedType(DatabindContext.java:163)
        at com.fasterxml.jackson.databind.ser.BeanPropertyWriter._findAndAddDynamic(BeanPropertyWriter.java:893)
        at com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:705)
        at com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:722)
        ... 85 common frames omitted

Is it some misconfiguration on my side? I am using jackson 2.10.1.

[frost13it]

@cowtowncoder Kotlin’s Nothing always get compiled into a raw type (actual type stays in Kotlin metadata) as described here. The issue can be reproduced in Java, please look at this gist.

[cowtowncoder]

If you do not want to include Type Id, then just do not use @JsonTypeInfo; there is no point in working around that if you have actual logic in (de)serializer, and use of 2 separate physical type is more of an implementation detail than type hierarchy to support.