Why IntelliJ IDEA Warns Only on @Autowired and a Detailed Comparison of @Autowired vs @Resource in Spring DI

Common DI Methods in Spring

Constructor Injection : inject dependencies via constructor parameters.

Setter Injection : inject dependencies by calling setter methods.

Field Injection : inject dependencies directly on fields using @Autowired or @Resource annotations.

@Autowired vs @Resource

Both annotations achieve dependency injection, but @Autowired is defined by Spring, while @Resource comes from the JSR‑250 specification. Their basic functionality is similar, yet they differ in several details:

Dependency Identification : @Autowired defaults to byType and can be qualified with @Qualifier for a name; @Resource defaults to byName and falls back to byType if no matching name is found.

Applicable Targets : @Autowired can be used on constructors, methods, parameters, and fields; @Resource is limited to methods and fields.

Provider : @Autowired is supplied by Spring itself, whereas @Resource is supplied by the JSR‑250 standard.

Advantages and Disadvantages of Different DI Styles

Constructor Injection : ensures strong dependency (must be present) and immutability of injected components.

Setter Injection : optional (component can work without the dependency) and allows mutable dependencies.

Field Injection : generally discouraged; if used, @Resource couples less tightly to the IoC container than @Autowired .

Drawbacks of Field Injection

Cannot inject immutable objects as easily as constructor injection.

Dependencies are hidden from external view, making it harder to understand required collaborators.

Creates tight coupling between the component and the IoC container, complicating usage outside the container.

Unit tests must involve the IoC container, increasing test complexity.

When many dependencies are present, the class may violate the Single Responsibility Principle.

Why IDEA Only Warns on @Autowired

Field injection is convenient, but @Autowired is a Spring‑specific annotation, tightly binding the code to Spring’s IoC container; changing to another container would break the injection. In contrast, @Resource follows the JSR‑250 Java standard, so IDEs treat it as a generic, container‑agnostic injection, resulting in no warning.