Register for reflection extension

[lujop]

Description

I created an extension for my own use to be able to register complete dependencies or packages using patterns: https://github.com/lujop/quarkus-register-reflection

For me, it's useful because it allows using of arbitrary external dependencies in an easy and fast way if a dedicated extension didn't exist. For example, in my case, I was developing a lambda function for a telegram bot using telegrambots library, and I needed to register many classes.

As that extension doesn't already exist I suppose that may be considered an antipattern, but I prefer to ask in that ticket.

Is it viable to be accepted in quarkiverse? If it is I will be happy to adapt and contribute to comply with the requeriments.

Configuration suggestion

No response

Additional context

No response

[gastaldi]

You can use https://quarkus.io/guides/cdi-reference#how-to-generate-a-jandex-index to index external dependencies and use @RegisterForReflection in your code (like in https://github.com/quarkusio/registry.quarkus.io/blob/main/src/main/java/io/quarkus/registry/app/Reflections.java#L27) to register specific classes for reflection

[lujop]

Thanks, @gastaldi, I already knew the annotations, but you have to do it for each class one by one, haven't you? Is there any way to put complete packages? Because for example in my case for telegrambot application there are a lot of API classes (more than 100), and doing them one by one doesn't seem the best way to me. It's tedious and error-prone, and if I update the library I need to check if there are new classes added. It's possible that all the classes aren't needed for reflection, but it will require me a lot of investigation time in the library internals that I prefer to avoid in this case.

I think that in some use cases there is a lot of value in being able to add complete packages. And other people seem to have the same needs: https://stackoverflow.com/questions/65798326/quarkus-native-reflection-configuration-for-whole-package If doing that with the @RefisterForReflection were possible I completely agree that this extension would be useless.

[gastaldi]

@lujop Right, that's not how this annotation was designed to work.

I agree that enabling a dependency to be native-compatible requires some investigation work and, based on my experience, not all classes from a library require reflection (as you also have pointed out), so you may skip a lot of classes and add only what's necessary using the @RegisterForReflection annotation. Adding unnecessary classes to be reflection-aware may hurt the performance of your native application and make the resulting executable to be considerably big, so yeah, doing it so is an anti-pattern IMHO. 😅

Going forward, in your case, I'd prefer having a quarkus-telegrambots extension, where you would declare the classes requiring reflection (where needed) to provide full native support for the TelegramBots library - which IMHO would be a good candidate to live in the Quarkiverse 😉

[quarkus-bot[bot]]

/cc @aloubyansky, @gastaldi, @gsmet, @maxandersen

[Mykiiii]

@lujop @gastaldi - We have one option where we can use a json file having all the packages we as recursive. Or we can make all the classes available for reflection.