Why Field Injection in Spring Is Discouraged and What to Use Instead

Introduction

When coding in IntelliJ IDEA, a warning appeared for a piece of Spring code that uses @Autowire on a field, prompting a closer look at dependency‑injection practices.

Warning Message

Spring’s inspection reports: Field injection is not recommended . The Spring team advises “always use constructor‑based dependency injection in your beans and use assertions for mandatory dependencies.”

Injection Types

Spring actually supports three main injection styles:

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‑based injection

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

Drawbacks of Field Injection

Cannot be used with final fields because Spring injects via setters after object construction.

Obscures the single‑responsibility principle ; a large constructor makes the class look overly complex, while field injection hides the true dependencies.

Creates tight coupling with Spring’s IoC container, making the class hard to use outside the container.

Hides dependencies by keeping them private , reducing the class’s explicit contract.

Prevents early validation of injected beans; null‑related errors surface only at runtime instead of during startup.

Conclusion

Field injection has many disadvantages and should be avoided. Prefer constructor‑based injection for mandatory dependencies to make them immutable and non‑null, and use setter‑based injection for optional dependencies.