Deserialization of `@JsonTypeInfo` annotated type fails with missing type id even for explicit concrete subtypes

[kilink]

When attempting to deserialize to a concrete class that is part of a polymorphic type hierarchy, an InvalidTypeIdException is thrown if the JSON does not contain the type id field. Example:

@JsonTypeInfo(
    use = JsonTypeInfo.Id.NAME,
    property = "type")
@JsonSubTypes({
    @JsonSubTypes.Type(value = Foo.class, name = "foo"),
    @JsonSubTypes.Type(value = Bar.class, name = "bar")})
public interface Base {}

public class Foo implements Base {}

public class Bar implements Base {}

ObjectMapper mapper = new ObjectMapper();

mapper.readerFor(Foo.class).readValue("{}"); // throws InvalidTypeIdException
mapper.readValue("{}", Foo.class); // throws InvalidTypeIdException

While I understand why this happens, as Jackson is finding the JsonTypeInfo / JsonSubTypes annotations on the interface, it is counterintuitive to me. In this instance, I am instructing the mapper as to the specific concrete class to deserialize to, so consulting those annotations seems unnecessary. Perhaps checking if the class / type supplied to readerFor / readValue matches exactly one of the classes listed in JsonSubType could be a fallback if the type id property is not found?

So far, the only workaround I've found is to do something like this:

@JsonTypeInfo(use = JsonTypeInfo.Id.NONE)
public class Foo implements Base {}

but then that means serializing a Foo instance would not get the type id property. Perhaps a custom TypeIdResolver or SubTypeResolver could also be used, but having the described behavior baked in seems like a sensible default to me. Thoughts?

[kupci]

I'd be interested in more about the particular use case for this, but setting that aside for the moment, I could possibly see one benefit, of a small performance gain, i.e. bypass the annotations check if there's nothing supplied.

Perhaps checking if the class / type supplied to readerFor / readValue matches exactly one of the classes listed in JsonSubType could be a fallback if the type id property is not found?

Assuming this is a reasonable improvement, given the above, do you have a PR to show your thinking on this? Also (going back to the use case), not clear on how big of a hit this would be, i.e. how often would this apply? This seems to be a very narrow scenario.

[cowtowncoder]

Ok, I think there already an issue for improving handling in this case (will see if I can find it). It would be nice to make type id optional for concrete case but it seems rather difficult to make work reliably due to delegating nature of things.

[kilink]

Here's an example. We have a tool that generates Java / Kotlin classes from GraphQL schemas, so given an example trivial schema:

interface Animal {
  name: String
}

type Dog implements Animal {
  name: String
  barkVolume: Int
}
        
type Cat implements Animal {
  name: String
  lives: Int
}

type Query {
  animals: [Animal]
  dogs: [Dog]
  cats: [Cat]
}
       

We might generate the following for the Animal interface so that query for animals works correctly:

@JsonTypeInfo(
    use = JsonTypeInfo.Id.NAME,
    include = JsonTypeInfo.As.PROPERTY,
    property = "__typename"
)
@JsonSubTypes({
    @JsonSubTypes.Type(value = Dog.class, name = "Dog"),
    @JsonSubTypes.Type(value = Cat.class, name = "Cat")
})
public interface Animal {
  String getName();
}

Now when queries are also built using our codegen tool, we can always arrange for the __typename meta field to be returned, but some users may opt to only use the generated types and build their own queries by hand. To us the generated class even when querying for a specific type like Dog, they need to remember to also always ask for __typename, which seems a little strange to have to do if they are indicating at time of deserialization they know the concrete type based on the query they're performing.

I can also think of non-GraphQL scenarios, where the client is using generated code and doing similar queries for REST endpoints like /animals, /dogs, and the server component is perhaps not using the same classes at all or is written in a different language. Yes, the /dogs endpoint could return JSON with type ids, but it seems redundant to have to do that when the client is specifically asking for a "concrete type" in this case.

[kilink]

Assuming this is a reasonable improvement, given the above, do you have a PR to show your thinking on this? Also (going back to the use case), not clear on how big of a hit this would be, i.e. how often would this apply? This seems to be a very narrow scenario.

I have not implemented a fix for this yet, but did begin digging around to see if it's possible. I tried to give some more context on the use case in my previous comment.

[cowtowncoder]

Could not find clear example, but #2063 is similar.

I would be open to a PR that would accept missing type id in case of concrete subtype being requested, and have been planning on working on making this possible (but it did not make it in 2.12).

@kupci Annotation processing would not be optimized: they are checked when constructing (de)serializers, once, and never during runtime.

[cowtowncoder]

Since I cannot quite find a more up-to-date issue, I will mark this one as "most-wanted" one -- and may also close older ones that seem like they would be solved with this one.

[alessiostalla]

Another related use case may be the following:

@JsonTypeInfo(
    use = JsonTypeInfo.Id.NAME,
    include = JsonTypeInfo.As.PROPERTY)
abstract class MyGeneralDomainObject {
    String id; //property
}

class A extends MyGeneralDomainObject {
    MyGeneralDomainObject obj; //here, we need type information
}

class B extends MyGeneralDomainObject {
    A propertyWithExplicitType; //here, we know the type is A, so if A doesn't have subclasses, why should we require type information in the JSON?
}