It would be beneficial if the framework allows all it’s necessary bits and pieces without relying on reflection so thoroughly.
This would be in line with technologies like GraalVM and might serve as a stepping stone to more closely support things like Micronaut and Quarkus.
Impl. Idea
Tackling #3067 first is paramount for this issue to be feasible.
From there, we need to investigate what components remain.
The LifecycleHandlers pop to mind as one of these components.
However, there's already an alternative aside from the annotation-based (thus using reflective logic) for this.
Validating if all components using reflection have this alternative, is thus important.
Once non-reflective solutions are present for the majority of components, it might be valuable to have a hard switch within the configuration to disable reflection altogether.
Although easier said than done, figuring out whether this is feasible would be a nice hand gesture for users who want to enforce this.
Workaround
The Spring Native Extension solves the predicament of using GraalVM by registering the components that use reflection.
Keeping this in mind and finding a means to have something similar for solutions like Micronaut and Quarkus wouldn't hurt.
Furthermore, there's a chance that we would lose valuable features when we would eliminate reflection use altogether.
For those cases, it would be paramount to provide the required information, as is currently done in our Spring Native extension.
Description
It would be beneficial if the framework allows all it’s necessary bits and pieces without relying on reflection so thoroughly. This would be in line with technologies like GraalVM and might serve as a stepping stone to more closely support things like Micronaut and Quarkus.
Impl. Idea
Tackling #3067 first is paramount for this issue to be feasible.
From there, we need to investigate what components remain. The
LifecycleHandlerspop to mind as one of these components. However, there's already an alternative aside from the annotation-based (thus using reflective logic) for this. Validating if all components using reflection have this alternative, is thus important.Once non-reflective solutions are present for the majority of components, it might be valuable to have a hard switch within the configuration to disable reflection altogether. Although easier said than done, figuring out whether this is feasible would be a nice hand gesture for users who want to enforce this.
Workaround
The Spring Native Extension solves the predicament of using GraalVM by registering the components that use reflection. Keeping this in mind and finding a means to have something similar for solutions like Micronaut and Quarkus wouldn't hurt.
Furthermore, there's a chance that we would lose valuable features when we would eliminate reflection use altogether. For those cases, it would be paramount to provide the required information, as is currently done in our Spring Native extension.