@ComponentScan
creates beans using both @Configuration
and @Component
. Both these annotations work fine when swapped. What is the difference then?

- 15,148
- 7
- 31
- 57

- 1,103
- 2
- 8
- 4
-
1http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/stereotype/Component.html, http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/annotation/Configuration.html – JB Nizet Aug 26 '16 at 21:12
-
4Thank you but please can you explain why these two work when interchanged – gaurav sood Aug 26 '16 at 21:24
-
10They don't, unless your configuration class does nothing that a configuration class would normally do. As said in the above linked documentation, Configuration is meta-annotated with Component, so a Configuration is a Component. The inverse is not true. – JB Nizet Aug 26 '16 at 21:26
-
Thanks JB for clearing my doubt – gaurav sood Aug 26 '16 at 21:50
8 Answers
@Configuration Indicates that a class declares one or more @Bean methods and may be processed by the Spring container to generate bean definitions and service requests for those beans at runtime
@Component Indicates that an annotated class is a "component". Such classes are considered as candidates for auto-detection when using annotation-based configuration and classpath scanning.
@Configuration is meta-annotated with @Component, therefore @Configuration classes are candidates for component scanning
You can see more here:
A @Configuration is also a @Component, but a @Component cannot act like a @Configuration.
-
46
-
1
-
The answer doesn't explain anything. Take note that `@Bean`s can be declared in `@Component` classes as well (or in other words, the first sentence of the linked Javadoc is misleading, at best). – Martin Andersson Aug 30 '23 at 14:37
There is a very subtle difference between them. Let me provide a very quick outlook to this.
Consider the below scenario:
@Configuration
public class MyConfig {
@Bean
public ServiceA aService(){
return new ServiceA();
}
@Bean
public ServiceB bService(){
return new ServiceB(aService());
}
}
Note that ServiceB
bean has a dependecy on ServiceA
and this is not autowired. Instead, the way it's written implies that a new instance is created, which is not actually created by Spring. You, the programmer, did it with the new
keyword instead.
So, if we do use @Configuration
, then it uses CGLIB proxying, and in this situation it creates a singleton bean managed by the Spring context. If you invoke it multiple times, it returns the same bean that was created by Spring - sort of autowiring effect.
Whereas if you use @Component
, it won't do this proxying and will simply return a new instance every time the method is invoked, instead of providing the Spring managed instance. (Remember that a Spring bean is something that is managed by the Spring container, and, as a developer, it's your job is to pull them in, e.g. with @Autowired
.
The same @Component
effect can be achieved with @Configuration(proxyEnabled= false)
(This is also referred to as bean light mode processing). So, in light mode, you would end up doing something like this:
@Configuration(proxyEnabled = false) // Lite mode, same effect as @Component
public class MyConfig {
@Bean
public ServiceA aService() {
return new ServiceA();
}
@Autowired
@Bean
public ServiceB bService(ServiceA aServiceBean){
return new ServiceB(aServiceBean);
}
}
Refer here for a more elaborate explanation
Hope that helps! Happy Coding!

- 2,175
- 1
- 21
- 24
Actually answer is not complete, is it true that:
@Component Indicates that an annotated class is a "component". Such classes are considered as candidates for auto-detection when using annotation-based configuration and classpath scanning.
But you do can create i.e MyConfiguration.java class then stereotype with @Component
and add @Beans
declaration to it. In this way it will looks as a configuration, main difference is that when annotated class with @Configuration
@Bean
annotated methods are proxy using CGLIB which made in code calls after the first one to return bean from context instead of execute method again and create another instance as happens when using @Component with @Bean

- 3,513
- 1
- 26
- 26
-
As per the code https://github.com/spring-projects/spring-framework/blob/master/spring-context/src/main/java/org/springframework/context/annotation/ConfigurationClassUtils.java @Component satisfies isConfigurationCandidate and as per my understanding it satisfies to be a Configuration class . Will there be a difference in behaviour as explained ? – R.G Oct 21 '19 at 07:16
-
1@Juan Rada: Would you give a real-world example where `@Component` and `@Bean` are called for, instead of `@Configuration` and `@Bean`? Does the former have to do with parallelism? – Treefish Zhang Jul 26 '21 at 17:10
-
@TreefishZhang [Anand's asnwer](https://stackoverflow.com/a/68836785/1868371) provides an example where this distinction is important. I don't think it has anything to do with parallelism though. – Gerardo Cauich Jan 10 '22 at 00:56
-
Has this changed? I tried both `@Component` and `@Configuration`. None of them execute the `@Bean` method more than once. – Wit May 17 '22 at 16:48
@Configuration - It is like beans.xml but Java-based bean configuration. It means class annotated with this annotation is the place where beans are configured and will be a candidate for auto-detection. In this class, methods are annotated with @Bean which return an object of the class.
Example:
@Configuration
public class ConfigClass {
@Bean
public UserClass getObject() {
return new UserClass();
}
}
@Component - You cannot autowire (@Autowired) any class if it is not marked with @Component. It means when you want to autowire any class using annotation that class should be annotated with @Component.
Example:
@Component
public class A { .... }
public class B {
@Autowired
A a;
.....
.....
}
Spring Document for reference: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/annotation/Configuration.html

- 2,320
- 1
- 15
- 34

- 179
- 1
- 5
-
1I believe the second statement at `@Component` needs clarification, because as it is, it is not entirely correct. `@Autowire` marks fields/parameters to be injected by the framework with Spring bean instances. However, `@Component` only marks classes to be auto-detected through component scan (there are various other marker annotations btw), and that's not a requirement. Bean instances can be created in other ways, like through `@Configuration` classes, factories, declaratively through xml configurations, etc. – Pawel Zieminski Mar 20 '19 at 16:43
@Component
is imported by default with @Configuration
. controllers, service, and repostory are children components (along with Configuration). They are also candidate for auto-detection.

- 6,233
- 16
- 73
- 108
I am extending on @reus's answer.
- @Configuration Indicates that a class declares one or more
@Bean
methods and may be processed by the Spring container to generate bean definitions and service requests for those beans at runtime. - If you look at the
@Configuration
class, you will see that it is meta-annotated with@Component
.
@Target(value=TYPE)
@Retention(value=RUNTIME)
@Documented
@Component
public @interface Configuration
@Bean
is enables us to define the dependency in any way we like, this is why the@Bean
annotation goes above a methods and we manually create a bean object and return it from that method.@Component
enables us to define a dependency quickly, that is why@Component
goes above classes. We only inject it wherever we need.
Collectively these 3 points says that- to quickly define a bean, we can annotate the class with @Component
. To define a bean as we like (support custom requirements), we can write the bean definition using @Bean
inside a @Configuration
annotated class.

- 49
- 8
@Configuration
and @Component
are both annotations used in Spring Framework, but they serve different purposes.
@Configuration
is a type-level annotation that indicates that a class declares one or more @Bean
methods and may be processed by the Spring container to generate bean definitions and service requests for those beans at runtime. Classes annotated with @Configuration
are usually used as sources of bean definitions.
@Component
is a class-level annotation that indicates that an annotated class is a "component". Such classes are considered as candidates for auto-detection when using annotation-based configuration and classpath scanning. It is a generic stereotype for any Spring-managed component or bean.
In simple terms, @Configuration
is used for defining beans and their dependencies, whereas @Component
is used for general-purpose auto-detection of components.
In most cases, you would use @Configuration
to define beans for complex configurations and @Component
to define simple beans that are used throughout your application.
Here are some official references that you may find helpful:
Spring Framework documentation: https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-java
@Configuration
JavaDoc: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/annotation/Configuration.html
@Component
JavaDoc: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/stereotype/Component.html

- 139
- 6
Apart from the differences highlighted by reos.
The reason why @Configuration cannot be replaced by @Component is as below:
The difference is in how the inter bean dependency is handled. Refer the link for a detailed explanation with example: Difference between Configuration and Component

- 306
- 3
- 6
-
1A link to a solution is welcome, but please ensure your answer is useful without it: [add context around the link](//meta.stackexchange.com/a/8259) so your fellow users will have some idea what it is and why it’s there, then quote the most relevant part of the page you're linking to in case the target page is unavailable. [Answers that are little more than a link may be deleted.](//stackoverflow.com/help/deleted-answers) – M.A.R. Apr 03 '17 at 09:51
-
Looking at the linked page, it only mentions the memo-ization features of the `@Configuration` as mentioned in the above answer by @jcrada but it doesn't mention anything about inter bean dependency handling. – Shadow Man Jul 25 '18 at 22:00