Consider the following use case:
@Configuration
public class Config {
@Bean(name = "myBean")
MyBean someBean() { ... }
@Bean(name = "myBean")
MyBean someBean(MyDependency) { ... }
}
The container accepts an override for myBean
as long as it is in the same configuration class to mimic the resolution of the greediest satisfiable constructors for bean factory methods.
Such an arrangement is much better served using Optional
or ObjectProvider
with a single bean factory method as it makes it explicit that some argument may or may not be available.
Comment From: jhoeller
Bean method overloading is effectively turned off by default as of 6.0, see #22609. From that perspective, formal deprecation does not seem urgent and might be better off in 7.0.
Comment From: jhoeller
The enforceUniqueMethods
flag is formally deprecated now, with the default true
being the only non-deprecated behavior now. This prevents regular use of overloaded factory methods as well as @Bean
method overrides with the same bean name but different method names. For the latter scenario, @Configuration(enforceUniqueMethods=false)
makes it work as before in 7.0 as well (previously that kind of arrangement was not covered by the enforceUniqueMethods
flag at all).