Overloaded @Bean method with name mismatch causes bean to be created twice (in case of ASM processing)

Reproduced in Spring 5.2.7.RELEASE (Spring Boot 2.3.1.RELEASE):

@Configuration
public class SomeConfig {
    @Bean(name = "other")
    SomeOtherBean foo() {
        System.out.println("constructing SomeOtherBean");
        return new SomeOtherBean();
    }

    @Bean(name = "foo")
    SomeBean foo(@Qualifier("other") SomeOtherBean other) {
        System.out.println("constructing SomeBean");
        return new SomeBean(other);
    }
}

With the above configuration class, SomeOtherBean is constructed twice, and SomeBean is never constructed. Why? Because the two methods have the same name. If you rename the second method to bar, everything is constructed once, as expected. Admittedly, using the same method name is not a good idea. I just happened to have done it by accident.

[jnizet]

@lifejwang11 not sure exactly what you mean by “the relationship between the two”. If you’re talking about the two beans SomeBean and SomeOtherBean, they’re irrelevant. Spring should construct an instance of each of them by calling each of the @Bean methods once, but does not, and instead calls the first one twice, and never calls the second one.

But anyway, here’s a complete demo if you want to try it by yourself: https://github.com/jnizet/spring-overload-issue

[jhoeller]

I’ve tracked this down to a difference between Class-based processing of the configuration class versus ASM-based processing against a registered configuration class name. A variant of the unit test passes with Class registration (similar to the @SpringJUnitConfig scenario above) but fails with name-based registration (similar to component scanning).