Why Field Injection Is Discouraged in Spring and Preferred Alternatives

While coding in IntelliJ IDEA a warning appeared for a field‑injection snippet, prompting an explanation of Spring's recommendation to avoid field injection in favor of constructor‑based dependency injection.

Spring’s official inspection message states: “Field injection is not recommended. Always use constructor‑based dependency injection in your beans. Always use assertions for mandatory dependencies.”

Spring actually supports three injection styles:

Constructor‑based injection

Setter‑based injection

Field‑based injection

Examples:

Constructor‑based injection:

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

Setter‑based injection:

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

Field‑based injection (the one that triggers the warning):

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

Although field injection is concise and widely used, it has several disadvantages:

It cannot be used with final fields, limiting immutability.

It hides the class’s dependencies, violating the Single Responsibility Principle and making constructors overloaded with many parameters.

It tightly couples the class to Spring’s IoC container, reducing portability.

It hides dependencies behind private fields, making it harder to detect missing or null beans at startup.

It prevents validation of injected values before the bean is used, delaying potential errors to runtime.

Conclusion: Avoid field injection. Prefer constructor injection for mandatory dependencies to ensure immutability and early failure, and use setter injection for optional dependencies. This leads to clearer, more testable, and decoupled backend code.