Minimise need to iterate over a class's methods

There are a number of places where Framework iterates over a class’s methods. This issue is intended to identify the places where the iteration is unnecessary and can be eliminated. ReflectionUtils keeps a per-Class cache of declared methods. To provide any significant benefit it will be necessary to eliminate all calls to ReflectionUtils for a particular class. It’s not yet known if this is possible.

AbstractAutowireCapableBeanFactory.determineTargetType uses the bean definition’s targetType to short-circuit type determination. When a bean is defined by ConfigurationClassBeanDefinitionReader processing a @Bean method, this type information is available but it is not used. If the metadata for the @Bean method is StandardMethodMetadata, the target type of the definition is available from the introspected method’s return type. Otherwise, the name of the target type is available from MethodMetadata.getReturnTypeName(). It appears to be possible for this type name to be stored in the definition and then be used to load the named class when getTargetType() is invoked.

When processing a ConfigurationClassBeanDefinition, ConstructorResolver.instantiateUsingFactoryMethod calls ReflectionUtils.getAllDeclaredMethods to find the Method for the @Bean method for which the bean definition was created. When the definition was created from StandardMethodMetadata, I think this method will already have been available and could, perhaps, have been stored in the definition’s resolvedConstructorOrFactoryMethod field. For ASM-based metadata, the method’s name is available and, with some changes to the metadata, it looks like its parameter types could be too. This may then allow the method to be identified directly without the need to iterate over all methods.

[wilkinsona]

Things have changed quite a bit in 2.2. We’re now using the resolved factory method that’s cached on the definition so overriding should not cause any problems. That said, please don’t point people to ConfigurationBeanFactoryMetadata. While it’s currently public we would prefer that it, or at least as much as possible of it, is not.

[wilkinsona]

Somewhat related to this, I think there is some benefit in making the factory method that’s used to create something defined using @Bean more readily available.

Boot supports the use of @ConfigurationProperties on a @Bean method, predominantly to support binding to third-party classes when annotating the class itself with @ConfigurationProperties isn’t possible. Boot has a class, ConfigurationBeanFactoryMetadata, that performs factory method discovery and caches its results. It would be more robust if the factory Method was directly available via the bean definition rather than having to duplicate the reflective search over the factory class’s methods to find the factory method.

Please let me know if you’d prefer for this piece to be tracked as a separate issue.