Minimise need to iterate over a class's methods

[wilkinsona]

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]

With some hacks in place to avoid the two occurrences described above, and with @Configuration class proxying disabled, we reach code that's iterating over the methods looking for annotations:

• CommonAnnotationBeanPostProcessor(and its super-class InitDestroyAnnotationBeanPostProcessor)
• AutowiredAnnotationBeanPostProcessor for honouring @Autowired
• AutowiredAnnotationBeanPostProcessor again when looking for @Lookup methods while determining constructors from bean post-processors
• Boot's own ConfigurationPropertiesBindingPostProcessor finding the bean's factory method to look for @ConfigurationProperties annotation

After these we move on to proxy creation in InfrastructureAdvisorAutoProxyCreator. There's a single advisor in the case I'm currently looking at, namely BeanFactoryTransactionAttributeSourceAdvisor. This results in iteration over all of the class's methods, looking for one to which the advice can apply. In this case it's looking for @Transactional so it's an annotation search again, but not as easy to avoid with an index due to the use of method-based matching.

Last of all (in the case I'm currently looking at) we get to EventListenerMethodProcessor looking for @EventListener methods. I'm cautiously optimistic that, with some changes in place to avoid the two occurrences described above and an annotation index, we could avoid all reflection over the methods of certain beans. The ability to opt out of configuration class proxying would increase the number of beans that falls into that category.

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

[jhoeller]

I'm about to commit an initial revision: a mechanism for bypassing method traversal for annotation introspection if possible. The isCandidateClass mechanism is consistently used for a bypass check before method traversal attempts now. While by default this is only bypassing standard java types (which never have annotations that we consider searchable), the same mechanism can be used with index metadata which indicates non-presence of certain annotations. All it takes is a more sophisticated implementation of AnnotationUtils.isCandidateClass(clazz, annotationName) which indicates non-presence of a specific annotation in a class (and its superclasses/interfaces); we'll revise that as part of our indexer efforts, ideally through a programmatic registration mechanism populated from index metadata on startup.

As for factory method resolution, I'll tackle this in a separate revision. An initial prototype works reasonably well. We just need to handle the rare cases of @Bean method overloads properly where we still need to apply our construction resolution algorithm against all candidate factory methods.

[jhoeller]

FWIW, that remaining part is only really trying to avoid full method traversal for pre-identified @Configuration classes... where the methods might have been traversed already, e.g. for finding @Bean methods with standard annotation metadata to begin with. It's worth addressing for the component scan case where the initial @Bean metadata comes from ASM but probably won't make much difference for Class-registered beans where the declared methods cache is populated already.