DefaultParameterNameDiscoverer should automatically adapt to Graal constraints [SPR-17005]

[spring-projects-issues]

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:

• Initial GraalVM native images (Substrate VM) support [SPR-16991] #21529 Initial GraalVM native images (Substrate VM) support ("is depended on by")
• Support platforms where Class is not Serializable in SerializableTypeWrapper [SPR-16992] #21530 Support platforms where Class is not Serializable in SerializableTypeWrapper
• Detect GraalVM with system property in SerializableTypeWrapper [SPR-17136] #21673 Detect GraalVM with system property in SerializableTypeWrapper

Referenced from: commits e8034f2

[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.