Interfaces are annotated with @Component annotation in spring IoC/DI. What could be the reason?

Question

Some times interfaces are annotated with @Component annotation. Then my obvious reasoning was that classes that implement such interface will be treated as components as we

Answer 1

Annotating an interface with @Component is common for Spring classes, particularly for some Spring stereotype annotations :

package org.springframework.stereotype;
...
@Component
public @interface Service {...}

or :

package org.springframework.boot.test.context;
...
@Component
public @interface TestComponent {...}

@Component is not declared as an inherited annotation :

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Component {...}

But whatever, during loading of the context, Spring discovers beans by considering the hierarchy of the annotation declared in the candidate class.

In the org.springframework.boot.BeanDefinitionLoader class (included in the Spring Boot dependency) that loads bean definitions from underlying sources, you can see an example of org.springframework.core.annotation.AnnotationUtils.findAnnotation() that Spring uses to retrieve annotations in the whole hierarchy of the annotation:

class BeanDefinitionLoader {
 ...
 private boolean isComponent(Class<?> type) {
    // This has to be a bit of a guess. The only way to be sure that this type is
    // eligible is to make a bean definition out of it and try to instantiate it.
    if (AnnotationUtils.findAnnotation(type, Component.class) != null) {
        return true;
    }
    // Nested anonymous classes are not eligible for registration, nor are groovy
    // closures
    if (type.getName().matches(".*\\$_.*closure.*") || type.isAnonymousClass()
            || type.getConstructors() == null || type.getConstructors().length == 0) {
        return false;
    }
    return true;
 }
 ...
}

Concretely, it means as the @Service annotation is itself annotated with @Component, Spring will consider a candidate class annotated with @Service as a bean to instantiate.

So, your guesswork is right :

Classes that implement such interface will be treated as components as well.

But this works only for interfaces (such as @Service) that are Java annotations and not for plain interfaces.

For Spring classes, this way of doing makes sense (enriching actual stereotype for example) but for your own beans, using @Component for the interface rather than the implementation will not work and would bring more drawbacks than advantages :

• it defeats in a same way the purpose of an interface that is above all a contract. It couples it to Spring and it supposes that you will always have a single implementation of the class.
  In this case, why using an interface ?

• it scatters the reading of the class at two places while the interface doesn't need to have any Spring stereotype.

Answer 2

That is not the case there is no need to adding @component on an interface because it is not a bean as we can't create reference for it. The main part is actually @autowired where you injection the dependecy. For example

public interface SortAlog(); public class BubbleSortAlgo();

No we are following the dynamic binding and creating the object of interface but implementation is on the run time.

So @autowired is the one that will create the object internally and we have @component for bubbleSortAlgo and the only candidate for the injection, so it will get reference from there.

I hope I was able to make a point here.