JsonTypeInfo.Id.DEDUCTION blocks signatures for non-instantiable classes

[Xfel]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

I have a class hierarchy with multiple levels of abstract classes that I want to deserialize in DEDUCTION mode.

If I explicitly add only the leaf classes as subtypes it works fine.

However I'm using kotlin and sealed classes, and here the intermediate levels are also registered. These intermediate level classes do not have a JsonCreator and are sealed/abstract, so they cannot be instantiated. I would expect the AsDeductionTypeDeserializer to simply ignore these types.

However, it does not do so and instead complains that these abstract types have the same signature.

Version Information

2.17.2

Reproduction

import com.fasterxml.jackson.annotation.JsonProperty
import com.fasterxml.jackson.annotation.JsonTypeInfo
import com.fasterxml.jackson.module.kotlin.jacksonObjectMapper
import com.fasterxml.jackson.module.kotlin.readValue

@JsonTypeInfo(use = JsonTypeInfo.Id.DEDUCTION)
sealed class Ingredient {
    sealed class Item: Ingredient() {
        abstract class Id(
            @JsonProperty("item")
            val id: String,
            val count: Int = 1,
        ): Item()
        data class Tag(
            @JsonProperty("tag")
            val tag: String,
            val count: Int = 1,
        ): Item()
    }
    sealed class Fluid: Ingredient() {
        data class Id(
            @JsonProperty("fluid")
            val id: String,
            val count: Int = 1000,
        ): Fluid()
        data class Tag(
            @JsonProperty("fluidTag")
            val tag: String,
            val count: Int = 1000,
        ): Fluid()
    }
}

fun main() {
    val mapper = jacksonObjectMapper()
    println(mapper.readValue<Ingredient>("""
        {
            "item": "test"
        }
    """.trimIndent()))
}

Expected behavior

No response

Additional context

jackson-module-kotlin only scans for direct subclasses of sealed classes, recursion in the hierarchy is handled by the core logic. Therefor this seems like an issue for this project.

[cowtowncoder]

@drekbour WDYT? Although in general it is difficult to determined viability of deserializing into given type (Jackson really knows by trying to figure it out), being abstract would be reliable "no can do" signal indeed.

[drekbour]

Sounds sensible to me

• cheap and a once-only cost during type registration
• doesn't invalidate/limit any other ideas floating around about hinting stuff to the deduction code