Introduction

Spring does not support @Autowired(required = false) on individual constructor parameters the way people often expect. For constructor injection, the idiomatic ways to make one dependency optional are Optional<T>, @Nullable, or ObjectProvider<T>.

Why required = false Is Not The Per-Parameter Answer

When Spring resolves a constructor, it decides how to satisfy the whole constructor signature. There is no separate required=false flag that you apply to just one parameter with ordinary constructor injection syntax.

So this is not the recommended model:

// conceptually what people want, but not the normal constructor pattern
public MyService(RequiredDep a, OptionalDep b) { ... }

Instead, Spring provides types and annotations that explicitly express optional constructor dependencies.

Use Optional<T>

This is often the cleanest modern choice:

1import java.util.Optional;
2import org.springframework.stereotype.Service;
3
4@Service
5public class MyService {
6    private final RequiredDep requiredDep;
7    private final Optional<OptionalDep> optionalDep;
8
9    public MyService(RequiredDep requiredDep, Optional<OptionalDep> optionalDep) {
10        this.requiredDep = requiredDep;
11        this.optionalDep = optionalDep;
12    }
13}

Spring injects an empty Optional if the bean is absent.

This is nice because the type itself communicates the dependency may not exist.

Use @Nullable If null Fits Your Style

Another option is a nullable constructor parameter:

1import org.springframework.lang.Nullable;
2import org.springframework.stereotype.Service;
3
4@Service
5public class MyService {
6    private final RequiredDep requiredDep;
7    private final OptionalDep optionalDep;
8
9    public MyService(RequiredDep requiredDep, @Nullable OptionalDep optionalDep) {
10        this.requiredDep = requiredDep;
11        this.optionalDep = optionalDep;
12    }
13}

Spring injects null if the bean is missing.

This works, but many teams prefer Optional<T> because it makes the optionality visible in the type system instead of relying on nullable conventions alone.

Use ObjectProvider<T> For Lazy Or Repeated Access

If you want optional lookup plus lazy access, ObjectProvider<T> is useful:

1import org.springframework.beans.factory.ObjectProvider;
2import org.springframework.stereotype.Service;
3
4@Service
5public class MyService {
6    private final RequiredDep requiredDep;
7    private final ObjectProvider<OptionalDep> optionalDepProvider;
8
9    public MyService(RequiredDep requiredDep, ObjectProvider<OptionalDep> optionalDepProvider) {
10        this.requiredDep = requiredDep;
11        this.optionalDepProvider = optionalDepProvider;
12    }
13
14    public void run() {
15        OptionalDep dep = optionalDepProvider.getIfAvailable();
16        if (dep != null) {
17            dep.execute();
18        }
19    }
20}

This is especially helpful when bean creation should be deferred or when access is conditional.

Prefer Constructor Injection Anyway

Even with optional dependencies, constructor injection is still a strong default because it keeps required and optional collaborators visible in one place.

If the number of optional dependencies grows too large, that is often a design smell. It may mean the class has too many responsibilities or that feature-specific behavior should be split into smaller components.

Optional injection is useful, but it should not become a way to hide overly broad object graphs.

Also remember that in modern Spring, if a class has a single constructor, you usually do not need to annotate that constructor with @Autowired at all. The optionality is expressed by the parameter type or annotation, not by putting special logic on the constructor itself.

Common Pitfalls

One common mistake is searching for a per-parameter required=false setting on constructor arguments when Spring's idiomatic answer is to use Optional, @Nullable, or ObjectProvider.

Another issue is using @Nullable and then forgetting to handle the null case defensively.

A third problem is injecting many optional beans into one class and turning the constructor into a sign that the class design needs refactoring.

Finally, some developers fall back to field injection for optional dependencies, even though constructor injection is usually clearer and easier to test.

Summary

• Spring does not use per-parameter required=false on constructor injection the way many developers first expect.
• Use Optional<T> for a clear, type-safe optional dependency.
• Use @Nullable when a nullable reference is acceptable.
• Use ObjectProvider<T> when you need lazy or conditional access.
• If many constructor dependencies are optional, reconsider the class design as well as the injection style.