Why Field Injection Is Discouraged in Spring and Preferred Alternatives

When editing code in IntelliJ IDEA, a warning appears for the following field injection:

@Autowire
private JdbcTemplate jdbcTemplate;

The warning states that field injection is not recommended and that the Spring team advises always using constructor‑based dependency injection and assertions for mandatory dependencies.

Spring’s documentation defines three main injection styles, although only two are officially listed:

Constructor‑based injection

public class UserServiceImpl implements UserService {
private UserDao userDao;
@Autowired
public UserServiceImpl(UserDao userDao) {
this.userDao = userDao;
}
}

Setter‑based injection

public class UserServiceImpl implements UserService {
private UserDao userDao;
@Autowired
public void setUserDao(UserDao userDao) {
this.userDao = userDao;
}
}

Field injection

public class UserServiceImpl implements UserService {
@Autowired
private UserDao userDao;
}

Field injection triggers a yellow‑card warning in IDEA because, despite its convenience, it has several drawbacks:

It cannot be used with final fields, which require constructor injection.

It obscures the class’s dependencies, violating the Single Responsibility Principle when many fields are injected.

It tightly couples the class to Spring’s IoC container, making the class harder to use outside the container.

Injected fields are private, hiding dependencies from external inspection and preventing early validation of null values.

It makes it difficult to perform runtime checks or custom validation on injected beans.

Because of these issues, the article recommends avoiding field injection and preferring constructor injection for mandatory dependencies (ensuring immutability) and setter injection for optional ones.

In summary, use constructor‑based injection whenever possible, fall back to setter injection for optional beans, and reserve field injection only for cases where its drawbacks are acceptable.