Clarify configuration lite support and offer an opt-in option

The Spring Boot team has been investigating startup time improvements by not relying on the proxy capabilities of configuration classes. Turns out that not using that stuff (basically switching all auto-configurations and related imports to “lite mode”) makes quite a difference https://github.com/spring-projects/spring-boot/issues/9068#issuecomment-461520814

I am not a big fan that we were looking for @Bean methods in any component, treating them in lite mode if they don’t have the @Configuration stereotype. I was wondering if we would be open to revisit this in the 5.2 line.

Being able to opt-out from the proxy mode using the @Configuration stereotype would be ideal. We are not keen to remove @Configuration and use the lite mode as it stands as:

• That’s not representative of what a good citizen of the framework should do (using the right stereotype)
• We have an annotation processor that identifies configuration classes to extract conditions so that we can back off (without loading the ASM metadata or the class) when a static condition does not match (i.e. class not on the classpath)

Having a way to opt-out would be also a nice opportunity to clarify the behaviour and stop scanning components for bean factory methods.

[jhoeller]

I have an implementation ready to be committed now, using a proxyBeanMethods flag as suggested above. (Even if this is technically not “proxying” in the AOP sense but rather method interception through overriding in the same instance, I suppose it can still be called proxying in a general sense.)

Whatever we may feel about it, I can’t see how we’d limit @Bean methods to @Configuration classes at this point… without breaking plenty of people who intentionally or unintentionally don’t use the @Configuration stereotype for some of their @Bean-declaring classes. This has been out there for 10 years and I am not inclined to break this, even if it is now possible to effectively get the same behavior using a new flag on @Configuration… Arguably the very fact that this is now a well-defined mode of regular configuration classes makes it easier to understand that the same behavior is applicable to individual @Bean methods outside of configuration classes as well, with less surprise that there is no method interception through CGLIB subclasses there, and that this is a proper variant of operation.

As for the annotation detection overhead, let’s tackle this along with our other issues for it. Once we have a method-level indication in the components index, we’ll get efficient skipping not only for @Bean checks but also for @EventListener, @Scheduled, @Transactional, the caching annotations etc. And if we introduce corresponding programmatic hints at the bean definition level, those should be equally applicable to the detection of all those method-level annotations so that we never reflectively iterate the methods of the affected component classes - not for @Bean detection and not for AOP proxying either.

[sbrannen]

While discussing this with @wilkinsona, I proposed we name the boolean flag in @Configuration something like proxyMethodInvocations = false analogous to proxyTargetClass in other places.

He came back with “proxyBeanMethodInvocations or perhaps proxyBeanMethods to make it clear that it’s only @Bean methods that are affected.”

I tend to like @Configuration(proxyBeanMethods = false) to turn off the default behavior.