Resource vs Autowired
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
@Autowired and @Resource can both inject dependencies in a Spring application, but they do not follow the same matching rules or convey the same intent. Understanding that difference matters because injection problems usually appear only after a project has several beans of the same type.
The main difference: type versus name
The shortest summary is:
- '
@Autowiredis Spring-native and primarily resolves by type' - '
@Resourcecomes from Jakarta annotations and is primarily name-oriented'
With @Autowired, Spring looks for a compatible bean type:
If there is exactly one PaymentGateway bean, injection is easy. If there are multiple candidates, you usually add @Qualifier.
By contrast, @Resource is often used when the bean name itself is the important selection rule:
That asks Spring for a bean with a specific name.
Why constructor injection changes the conversation
In modern Spring code, constructor injection is usually the best default. It makes dependencies explicit, helps testing, and avoids hidden mutable state.
That naturally favors @Autowired style semantics, and in many cases you do not even need the annotation on the constructor at all:
With a single constructor, Spring can wire it automatically. This is one reason @Autowired feels more natural in modern Spring applications than field-level @Resource.
When @Qualifier and @Resource overlap
If you have multiple beans of the same type, these two styles can look similar:
and:
Both point at the same bean, but they communicate intent differently. @Qualifier says "select this named candidate within Spring’s type-based model." @Resource says "inject the named resource."
Practical guidance
For most Spring-only codebases, a strong default is:
- prefer constructor injection
- prefer
@Autowiredsemantics, usually with no explicit annotation on a single constructor - add
@Qualifierwhen multiple beans share a type
Use @Resource when name-based injection is genuinely what you want, or when working with code that already follows Jakarta-style resource semantics.
The goal is not annotation variety. The goal is making dependency resolution obvious to future readers.
Subtle behavioral differences
There are a few practical distinctions worth remembering:
- '
@Autowiredworks naturally with constructors, fields, and setters' - '
@Resourceis commonly used on fields and setters, not constructor parameters' - '
@Autowiredintegrates closely with Spring features such as@Qualifier' - '
@Resourceemphasizes bean naming more directly'
Those differences matter most in larger applications where dependency graphs and bean names are no longer trivial.
Common Pitfalls
The biggest pitfall is field injection by habit. Whether you use @Autowired or @Resource, hidden field injection makes dependencies less obvious and harder to test than constructor injection.
Another issue is assuming @Resource and @Autowired are interchangeable. They may both inject a bean in simple cases, but ambiguity resolution behaves differently once multiple candidates exist.
People also overuse bean names as architecture. If everything depends on string bean names everywhere, refactoring becomes more fragile than it needs to be.
Finally, do not treat annotation choice as merely stylistic. It reflects how the dependency should be resolved, which directly affects maintainability and debugging.
Summary
- '
@Autowiredis Spring-native and primarily resolves dependencies by type.' - '
@Resourceis Jakarta-based and is primarily name-oriented.' - Constructor injection is usually the best modern default in Spring applications.
- Use
@Qualifierwith@Autowiredwhen multiple beans share the same type. - Choose the annotation that matches the resolution rule you actually want, not just the one that seems shorter.

