Spring dependency injection infers unexpectly the right bean

Having this interfaces/classes:

interface BankService {}

interface TransferService {}
 
class BankTransferServiceImpl implements BankService, TransferService {}

class BankingClient {
  public BankingClient(BankService bs) {}
}

As expected this main method will not compiled, because BankingClient constructor expects a BankService, not a TransferService type:

public static void main(String[] args) {
  TransferService ts = new BankTransferServiceImpl();
  BankingClient bs = new BankingClient(ts);
}

Then we have this Spring configuration file:

@Configuration
public class MyConfig {

  @Bean
  TransferService transferService() {
    return new BankTransferServiceImpl();
  }

  @Bean
  BankingClient bankingService(BankService bs) {
    return new BankingClient(bs);
  }
}

Similarly, I was expecting to get an error in bankingService method, because the only bean we have already is the TransferService, and TransferService does not extends BankService. But my junit runs and instantiate bankingService successfully. What am I missing?

> java
> public static void main(String[] args) {
> TransferService ts = new BankTransferServiceImpl();
> BankingClient bs = new BankingClient(ts);
>}
>

Spring creates beans in a different way:

• it stores information about beans have been created
• it stores information about how to create particular bean

basically, that could be represented by the following oversimplified code:

public static void main(String[] args) {
    List<Object> objects = new ArrayList<>();
    Map<Class, Supplier> suppliers = new HashMap<>();
    suppliers.put(TransferService.class, BankTransferServiceImpl::new);
    TransferService ts = new BankTransferServiceImpl();
    objects.add(ts);
    BankService bs = objects.stream()
            .filter(BankService.class::isInstance)
            .map(BankService.class::cast)
            .reduce((a, b) -> {
                throw new IllegalStateException("Multiple beans found");
            })
            .orElseGet(() -> {
                Supplier<?> supplier = suppliers.get(BankService.class);
                if (supplier == null) {
                    throw new IllegalStateException("No bean supplier found");
                }
                Object result = supplier.get();
                objects.add(result);
                return (BankService) result;
            });
    BankingClient client = new BankingClient(bs);
}

In your case bean initialisation order actually makes sense:

• at first spring creates TransferService bean
• after that spring "does know" that TransferService bean also implements BankService interface, and thus it can construct BankingClient instance

However, if you change definition order of beans in MyConfig configuration class:

@Configuration
public class MyConfig {

    @Bean
    BankingClient bankingService(BankService bs) {
        return new BankingClient(bs);
    }

    @Bean
    TransferService transferService() {
        return new BankTransferServiceImpl();
    }

}

you may get another behaviour:

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: 
    No qualifying bean of type 'BankService' available: 
     expected at least 1 bean which qualifies as autowire candidate.

just because spring does know how to create TransferService bean, but has no idea about how to create BankService bean, and TransferService bean has not been created yet.

Switching from factory methods (methods annotated by @Bean) to @ComponentScan/@Component changes behaviour of spring as well:

• in case of factory methods, spring initially infers bean type from factory method return type, and thus it may not have enough information about actual bean type
• in case of @ComponentScan/@Component, since spring does see the actual bean type it has more information about beans to be created.

You may also check AbstractBeanFactory#isTypeMatch method.