SpringBoot @ConditionalOnBean is affected by the order in which beans are declared in the file

@ConditionalOnBean is affected by the order in which beans are declared in the file. For example, I have a file with the following:

@AutoConfiguration
public class MyAutoConfiguration {

    @Bean
    @ConditionalOnBean(SomeType.class)
    public AnotherType anotherType(SomeType someType) { ... }

    @Bean
    public SomeType someType() { ... }
}

In this case AnotherType won't be instantiated. If I swap the order in which I declared the beans in the file, then it will be instantiated.

I believe the documentation mentions this behaviour (here).

You need to be very careful about the order in which bean definitions are added, as these conditions are evaluated based on what has been processed so far. For this reason, we recommend using only @ConditionalOnBean and @ConditionalOnMissingBean annotations on auto-configuration classes (since these are guaranteed to load after any user-defined bean definitions have been added).

Is this something that can be addressed in the future? When declaring beans without conditions the order is irrelevant, it would be nice if this could be the same when using conditions.

Comment From: wilkinsona

The order in which @Bean methods are processed and, therefore, the order in which their conditions are evaluated is determined by Spring Framework and is out of Spring Boot's control. I'm not aware of any plans to address the behavior you have observed in the future. I believe it would require too much knowledge about a condition's implementation to determine the "correct" ordering of the @Bean methods.

I presume your example above it only for demonstration purposes. You could remove the condition entirely and it would not change the behavior as there will always be a SomeType when anotherType is being processed. For more complex scenarios where the ordering becomes important, we recommend splitting things into multiple @Configuration classes and @Importing them in the desired order from the top-level @AutoConfiguration class.