Subtype resolution with unknown generics

[kevin-yu-0602]

Hi,
I have implemented a custom subtype resolver but am hitting into a problem when resolving a subclass of

Dog extends Animal<Optional<Void>> {

with a superclass of

Animal<T>

this is the same problem as FasterXML/java-classmate#53. Given that there does not yet seem to be a general fix for this issue, I was wondering if anyone had any suggestions around writing specific handling code just for this exact case.

[kevin-yu-0602]

This was being used in my custom subtype resolver and going from calling resolveSubtype

@Override
public List<ResolvedType> findSubtypes(ResolvedType declaredType, SchemaGenerationContext context) {
    Collection<Class<?>> subtypes = <custom subtype fetching behavior>
    if (resolvedSubtypes.isEmpty()) {
        return null;
    } else {
        TypeContext typeContext = context.getTypeContext();
        return resolvedSubtypes
                .stream()
                .map(subType -> typeContext.resolveSubtype(declaredType, subType))
                .collect(Collectors.toList());
    }
}

to directly calling resolve instead

        return resolvedSubtypes
                .stream()
                .map(typeContext::resolve)
                .collect(Collectors.toList());

seemed to have worked. But would still appreciate it if someone could check if resolveSubtype is actually needed here

[CarstenWickner]

Hi @kevin-yu-0602,

I'm unsure how to respond here, honestly.
This seems different to FasterXML/java-classmate#53, since the issue described there would occur for this:

class Dog extends Animal

with a superclass of

class Animal<T>

The lack of type parameter declaration is the issue there.

---

In your specific example, resolveSubtype is not technically required, but it is the safe way to go, in case you have this kind of setup:

class Dog<T> extends Animal<T>

and the member where the Subtype Resolver gets applied is something like this:

private Animal<Optional<Void>> field;

When you use typeContext.resolve(Dog.class) you interpret this as:

private Dog<?> field;

Using typeContext.resolveSubtype(declaredType, Dog.class) leads to this more accurate interpretation:

private Dog<Optional<Void>> field;

I.e., when the declared type may contain (generic) information, that helps specify the subtype, typeContext.resolveSubtype() is preferable here. That's at least the theory. 😬

---

As for your original question:

• What is the exact error?
• Can you provide a full reproducible example?

[kevin-yu-0602]

Hi @CarstenWickner,

I really appreciate the fast response, apologies my question was not super clear but your answer does clarify some things for me.
The exact error I am hitting is

Type parameter #1/1 differs; expected java.lang.Object, got java.util.Optional<Void>
java.lang.IllegalArgumentException: Type parameter #1/1 differs; expected java.lang.Object, got java.util.Optional<Void>
	at com.fasterxml.classmate.TypeResolver._resolveTypePlaceholders(TypeResolver.java:557)
	at com.fasterxml.classmate.TypeResolver.resolveSubtype(TypeResolver.java:280)
	at com.github.victools.jsonschema.generator.TypeContext.resolveSubtype(TypeContext.java:126)

and an example of this (sorry this example is not super minimal, I am trying to make it as close to my code as possible in case there is something else I may have messed up on)

    @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.EXISTING_PROPERTY, property = "type")
    interface Operation<T> {
        String getType();

        T getData();
    }

    @JsonTypeName("void")
    class Void implements Operation<Optional<Void>> {
        private final Optional<Void> data;

        Void(Optional<Void> data) {
            this.data = data;
        }

        @Override
        public String getType() {
            return "void";
        }

        @Override
        @JsonProperty("data")
        public Optional<Void> getData() {
            return Optional.empty();
        }
    }

    class MainObject {
        private final Operation<?> operation;

        MainObject(Operation<?> operation) {
            this.operation = operation;
        }

        @JsonProperty("operation")
        public Operation<?> getOperation() {
            return operation;
        }
    }

With this setup

SchemaGeneratorConfigBuilder configBuilder =
        new SchemaGeneratorConfigBuilder(SchemaVersion.DRAFT_2019_09, OptionPreset.PLAIN_JSON)
                .with(new JacksonModule(JacksonOption.ALWAYS_REF_SUBTYPES));

configBuilder.forTypesInGeneral()
.withSubtypeResolver((declaredType, context) -> {
    Class<?> type = declaredType.getErasedType();
    Collection<Class<?>> resolvedSubtypes = // custom behavior to fetch Void as a subtype of Operation
    if (resolvedSubtypes.isEmpty()) {
        return null;
    } else {
        TypeContext typeContext = context.getTypeContext();
        return resolvedSubtypes
                .stream()
                .map(typeContext::resolve)
                .collect(Collectors.toList());
    }
});
SchemaGenerator generator = new SchemaGenerator(configBuilder.build());
JsonNode jsonSchema =
        generator.generateSchema(MainObject.class);

I get the result

{
  "$schema" : "https://json-schema.org/draft/2019-09/schema",
  "$defs" : {
    "Void-1" : {
      "type" : "object",
      "properties" : {
        "data" : {
          "anyOf" : [ {
            "type" : "null"
          }, {
            "$ref" : "#/$defs/Void-2"
          } ]
        }
      }
    },
    "Void-2" : {
      "$ref" : "#/$defs/Void-1",
      "type" : "object",
      "properties" : {
        "type" : {
          "const" : "void"
        }
      },
      "required" : [ "type" ]
    }
  },
  "type" : "object",
  "properties" : {
    "operation" : {
      "$ref" : "#/$defs/Void-2"
    }
  }
}

but if I change the subtype resolution to

        return resolvedSubtypes
                .stream()
                .map(clazz -> typeContext.resolveSubtype(declaredType, clazz))
                .collect(Collectors.toList());

I get the error above

[CarstenWickner]

Yeah alright, I agree this looks similar to the java-classmate/#53 with the mismatching generic type parameter.
As you initially stated, this likely requires a fix on the classmate site and there's not much you can do here besides using typeContext.resolve() for now, while this is good enough for subtypes without passed-through type parameters.

Looks like you found a workaround (if not a solution) yourself. 😃

---

And just in case you don't like the Void-1 and Void-2 definitions, you might want to try out the JacksonOption.INLINE_TRANSFORMED_SUBTYPES.

[kevin-yu-0602]

Gotcha! I was trying JacksonOption.INLINE_TRANSFORMED_SUBTYPES as per your suggestion and I got a Stack Overflow error, would you happen to know why this might be the case? Does this maybe have to do with the fact that it seems like Void-1 Void-2 form cyclic references?

[CarstenWickner]

Ah, yes. The getData() makes it an endless loop. Then you can't use that here.

jsonschema-generator/jsonschema-module-jackson/src/main/java/com/github/victools/jsonschema/module/jackson/JacksonOption.java

Lines 75 to 84 in bdca6c5

	/**
	* Use this option to ensure all looked-up subtypes according to {@code @JsonSubTypes} annotations are referenced via the central "$defs". This
	* applies to the nested schema inside the wrapping object/array or "allOf" based on {@code @JsonTypeInfo} annotations. This can be used to
	* counter-act the {@link com.github.victools.jsonschema.generator.Option#DEFINITIONS_FOR_ALL_OBJECTS Option.DEFINITIONS_FOR_ALL_OBJECTS}.
	* Beware: as with every explicit inlining, recursive non-transformed references can result in a stack overflow during schema generation when this
	* option is enabled (similar to {@link com.github.victools.jsonschema.generator.Option#INLINE_ALL_SCHEMAS Option.INLINE_ALL_SCHEMAS})!
	*
	* @since 4.30.0
	*/
	INLINE_TRANSFORMED_SUBTYPES,

Then you have to accept the two definitions. 😬