Overloaded @Bean methods in @Configration class are processed in inconsistent order

[littlesky007]

for example:

@Configuration
public class MyConfigurauion {

	@Bean
	@Lazy
	public Mytest mytest() {
		System.out.println("lazy");
		return new Mytest();
	}

	@Bean
	public Mytest mytest(MyConfigurauion m) {
		System.out.println("not Lazy");
		return new Mytest();
	}

	public static void main(String[] args) {
		AnnotationConfigApplicationContext app = new AnnotationConfigApplicationContext();
		app.setAllowBeanDefinitionOverriding(false);
		app.register(MyConfigurauion.class);

		app.refresh();
		MyConfigurauion bean = app.getBean(MyConfigurauion.class);
		System.out.println("init done");
		bean.mytest();
	}
}

spring analysis @Bean in retrieveBeanMethodMetadata method, Set<MethodMetadata> beanMethods = original.getAnnotatedMethods(Bean.class.getName()) line disorder,so get different result;

[littlesky007]

spring version 5.3.29

[snicoll]

I don't know what you mean by disorder. Perhaps you're expecting that calling mytest with no argument is going to return you the @Lazy version. This configuration isn't configuring two beans, it's the same bean with two factory methods and the container chooses the one with the most argument it can honor. In this case, the method that takes the configuration will be chosen to create the bean.

Having multiple factory methods for the same bean is actually going to be deprecated in 6.2.x, see #31073.

[littlesky007]

yes, but there also has a problem. the result is not regular, it maybe 'init done/n/r not lazy',and it also maybe 'not lazy /n/r init done'. I think retrieveBeanMethodMetadata(SourceClass sourceClass) has a little bug in Set beanMethods = original.getAnnotatedMethods(Bean.class.getName()); because Class.getDeclareMethods is disorder.