Dave Syer opened SPR-17005 and commented
ParameterNameDiscoverer is used in a number of places in Spring, not least of which is in the core DI features. AbstractAutowireCapableBeanFactory exposes a setter and a getter, but it's not available in any public interfaces that are easy to access, so it seems like you have to resort to downcasting:
((AbstractAutowireCapableBeanFactory) context.getDefaultListableBeanFactory())
.setParameterNameDiscoverer(...);
MVC and Webflux also use parameter name discovery for controller methods. This can be avoided if users explicitly add annotations, or simply don't use the flexible method signature features.
The default parameter name discoverer uses reflection and also ASM, and both of these strategies is problematic or unavailable in native images (c.f. GraalVM). It seems like the AbstractAutowireCapableBeanFactory actually works fine with a NoopParameterNameDiscoverer (that just returns null), unless it has to do autowire by name (which is pretty uncommon I should think).
Issue Links: - #21529 Initial GraalVM native images (Substrate VM) support ("is depended on by") - #21530 Support platforms where Class is not Serializable in SerializableTypeWrapper - #21673 Detect GraalVM with system property in SerializableTypeWrapper
Referenced from: commits https://github.com/spring-projects/spring-framework/commit/e8034f2f967ec61a9f5393ec3f93c1d8e373f155
Comment From: spring-projects-issues
Sébastien Deleuze commented
Resolved by using no ParameterNameDiscoverer with Graal native images via org.graalvm.nativeimage.imagecode system property (which is considered as a public API) as advised by GraalVM team, see ImageInfo.java.