Is there a way to mark a specific class for reflection free serializer generation?

[HartlIKS]

Because of similarities, several rest endpoints in a quarkus application I am developing are defined in a generic abstract class. The DTO type is one of the generic type arguments of this abstract class.

This causes the discovery for the reflection free serializer generator to not find these DTO classes, which I am not surprised by (due to type erasure of generics).
Is there a way I can explicitly mark these DTO classes to force them to be discovered?

[MILLERMARRU]

I ran into the exact same problem with an abstract generic REST base class. The reflection-free serializer feature (quarkus.rest.jackson.optimization.enable-reflection-free-serializers, part of quarkus-rest-jackson) doesn't discover your DTO because of how it finds classes to generate serializers for. I checked the build step in ResteasyReactiveJacksonProcessor.handleEndpointParams: for every resource method it calls methodInfo.returnType() and resolves that Jandex Type straight to a ClassInfo via indexView.getClassByName(...). If the @GET/@POST method is only declared in your abstract class and the DTO type is a generic type parameter (T), the Jandex bytecode signature for that method's return type is a type variable, not a resolved class, so getEffectiveClassInfo can't map it to your concrete DTO and it never lands in the serializedClasses/deserializedClasses maps that get handed to the serializer generator.

Since the discovery walks the actual annotated resource method as it exists in the bytecode (not the runtime instance), inheriting the endpoint from the generic abstract class without a concrete override never resolves T for the scanner, no matter how many subclasses extend it with a real type argument.

The fix that works without falling back to reflection: override the endpoint method itself in each concrete resource subclass with the resolved return type, even if the body just delegates to super:

public abstract class AbstractResource<T> {
    @GET
    public T get() {
        return doGet();
    }
    protected abstract T doGet();
}

@Path("/widgets")
public class WidgetResource extends AbstractResource<WidgetDto> {
    @GET // re-declare with a concrete return type so it gets indexed correctly
    @Override
    public WidgetDto get() {
        return super.get();
    }
    // ...
}

Once WidgetResource.get() itself carries a resolved WidgetDto return type in its own class file, the build step picks it up like any other endpoint and generates the StdSerializer/StdDeserializer for it. It's a bit of boilerplate per subclass, but it keeps you on the reflection-free path instead of quietly falling back to reflection for these DTOs (which a native build would then need @RegisterForReflection for anyway).

[HartlIKS]

This works for top-level DTO classes, but it breaks if you have a generic outer DTO.
E.g.

public record PageDTO<T>(
    int number,
    int size,
    int totalElements,
    int totalPages,
    List<T> content
) {}

@GET
public PageDTO<OtherDTO> getPage(@RestQuery int number, @RestQuery int size) {}

PageDTO is being picked up, but OtherDTO is not.

[cescoffier]

/CC @mariofusco

[mariofusco]

See #56238

[mariofusco]

The pull request linked above (already merged on main) should solve improve the type discovery and trigger the generation of the Jackson serializer also for the situation explicitly reported here #56013 (reply in thread)

As I wrote in the comment to that pull request, for now I'm not adding any mechanism to explicitly mark a specific class for reflection free serializer generation because I'd like that the discovery could be as automatic as possible.

I will eventually add it only if and when we will find that there is a situation where it is impossible to automatically infer it. For this reason I'm closing this discussion for now, but feel free to reopen it (or to send a proper bug report) if you can find any other situation where a reflection-free Jackson serializer should be generated but it's missing.