Software Dev March 22, 2026 14 min read Java Performance Engineering Series

Table of Contents

1. Why Dependency Injection Is Misunderstood in Spring
2. Constructor Injection vs Field Injection: The Real Difference
3. @Autowired, @Qualifier, and @Primary: When to Use What
4. Circular Dependency Traps and How to Break Them
5. Lazy Initialization and @Lazy
6. ApplicationContext vs BeanFactory: When to Inject the Context
7. Designing Testable Spring Components
8. Real Production Failure Scenarios
9. Key Takeaways
10. Conclusion

The fundamental question: Can you instantiate your class with new ClassName(...) in a unit test, passing mock dependencies? If no, your DI design is broken.

// ❌ Field injection - common but problematic
@Service
public class OrderService {
    @Autowired
    private CustomerRepository customerRepository;
    
    @Autowired
    private PaymentService paymentService;
    
    @Autowired
    private NotificationService notificationService;
}
// Problems:
// 1. Cannot instantiate without Spring - untestable
// 2. Dependencies are hidden - not visible in constructor signature
// 3. Allows partial initialization - NPE risk
// 4. Immutability impossible - fields can't be final
// 5. Easy to add too many dependencies - design smell hidden
// ✅ Constructor injection - explicit and testable
@Service
public class OrderService {
    private final CustomerRepository customerRepository;
    private final PaymentService paymentService;
    private final NotificationService notificationService;
    
    // @Autowired optional since Spring 4.3 for single constructor
    public OrderService(
            CustomerRepository customerRepository,
            PaymentService paymentService,
            NotificationService notificationService) {
        this.customerRepository = customerRepository;
        this.paymentService = paymentService;
        this.notificationService = notificationService;
    }
}
// Benefits:
// 1. Testable: new OrderService(mockRepo, mockPayment, mockNotification)
// 2. Dependencies explicit in signature
// 3. Immutable: fields are final
// 4. Too many dependencies = too many constructor params = obvious smell

Spring recommendation: The Spring team officially recommends constructor injection for mandatory dependencies. Use setter injection only for optional dependencies that have reasonable defaults.

// Interface with multiple implementations
public interface PaymentProcessor {
    void process(Payment payment);
}
@Component("stripeProcessor")
public class StripePaymentProcessor implements PaymentProcessor { ... }
@Component("paypalProcessor")
public class PayPalPaymentProcessor implements PaymentProcessor { ... }
@Component("squareProcessor")
@Primary  // Default when no qualifier specified
public class SquarePaymentProcessor implements PaymentProcessor { ... }
// Using @Primary - injects Square by default
@Service
public class CheckoutService {
    private final PaymentProcessor processor; // Gets SquarePaymentProcessor
    
    public CheckoutService(PaymentProcessor processor) {
        this.processor = processor;
    }
}
// Using @Qualifier - explicitly choose implementation
@Service
public class RefundService {
    private final PaymentProcessor processor;
    
    public RefundService(@Qualifier("stripeProcessor") PaymentProcessor processor) {
        this.processor = processor;
    }
}
// Injecting all implementations
@Service
public class PaymentRouter {
    private final List<PaymentProcessor> processors; // All implementations
    
    public PaymentRouter(List<PaymentProcessor> processors) {
        this.processors = processors;
    }
}

// Circular dependency - ServiceA needs ServiceB, ServiceB needs ServiceA
@Service
public class OrderService {
    private final CustomerService customerService; // CustomerService needs OrderService!
    
    public OrderService(CustomerService customerService) {
        this.customerService = customerService;
    }
}
@Service
public class CustomerService {
    private final OrderService orderService; // Circular!
    
    public CustomerService(OrderService orderService) {
        this.orderService = orderService;
    }
}
// Result: BeanCurrentlyInCreationException at startup
// ✅ Solution 1: Extract shared logic into third service
@Service
public class OrderCustomerLinkService {
    // Logic that both services need
}
// ✅ Solution 2: Use events to decouple
@Service
public class OrderService {
    private final ApplicationEventPublisher eventPublisher;
    
    public void createOrder(Order order) {
        // Process order
        eventPublisher.publishEvent(new OrderCreatedEvent(order));
    }
}
@Service
public class CustomerService {
    @EventListener
    public void onOrderCreated(OrderCreatedEvent event) {
        // React to order creation without direct dependency
    }
}
// ✅ Solution 3: Lazy injection (use sparingly)
@Service
public class OrderService {
    private final Lazy<CustomerService> customerService;
    
    public OrderService(@Lazy Lazy<CustomerService> customerService) {
        this.customerService = customerService;
    }
}

Design smell: Circular dependencies usually indicate a design problem — two services are too tightly coupled or should be one service. Fix the design, don't just work around the error.

// Bean created on first getHeavyService() call, not at startup
@Service
@Lazy
public class HeavyReportingService {
    public HeavyReportingService() {
        // Expensive initialization - database connections, file loading, etc.
    }
}
// Lazy injection - HeavyService created when first accessed
@Service
public class DashboardService {
    private final HeavyReportingService reportingService;
    
    public DashboardService(@Lazy HeavyReportingService reportingService) {
        this.reportingService = reportingService; // Proxy injected, not real bean
    }
    
    public Report generateReport() {
        return reportingService.generate(); // Real bean created here
    }
}
// Global lazy initialization (Spring Boot 2.2+)
// application.yml
spring:
  main:
    lazy-initialization: true  # All beans lazy by default

// ✅ Valid use: Dynamic bean lookup based on runtime condition
@Service
public class ProcessorFactory {
    private final ApplicationContext context;
    
    public ProcessorFactory(ApplicationContext context) {
        this.context = context;
    }
    
    public PaymentProcessor getProcessor(PaymentMethod method) {
        String beanName = method.name().toLowerCase() + "Processor";
        return context.getBean(beanName, PaymentProcessor.class);
    }
}
// ❌ Anti-pattern: Using context to avoid constructor injection
@Service
public class BadService {
    @Autowired
    private ApplicationContext context;
    
    public void doSomething() {
        // This defeats the purpose of DI!
        CustomerService cs = context.getBean(CustomerService.class);
        cs.findCustomer();
    }
}
// ✅ Better: ObjectProvider for optional/lazy beans
@Service
public class NotificationService {
    private final ObjectProvider<SlackClient> slackClient;
    
    public NotificationService(ObjectProvider<SlackClient> slackClient) {
        this.slackClient = slackClient; // May not exist in all environments
    }
    
    public void notify(String message) {
        slackClient.ifAvailable(client -> client.send(message));
    }
}

// Service designed for testability
@Service
public class OrderService {
    private final OrderRepository orderRepository;
    private final PaymentService paymentService;
    private final Clock clock; // Inject clock for time-based testing!
    
    public OrderService(
            OrderRepository orderRepository,
            PaymentService paymentService,
            Clock clock) {
        this.orderRepository = orderRepository;
        this.paymentService = paymentService;
        this.clock = clock;
    }
    
    public Order createOrder(OrderRequest request) {
        Order order = new Order();
        order.setCreatedAt(LocalDateTime.now(clock)); // Testable!
        // ...
        return orderRepository.save(order);
    }
}
// Unit test - NO SPRING CONTEXT NEEDED
class OrderServiceTest {
    private OrderService orderService;
    private OrderRepository mockRepository;
    private PaymentService mockPaymentService;
    private Clock fixedClock;
    
    @BeforeEach
    void setUp() {
        mockRepository = mock(OrderRepository.class);
        mockPaymentService = mock(PaymentService.class);
        fixedClock = Clock.fixed(Instant.parse("2026-03-22T10:00:00Z"), ZoneOffset.UTC);
        
        // No Spring! Just plain Java
        orderService = new OrderService(
            mockRepository, 
            mockPaymentService, 
            fixedClock
        );
    }
    
    @Test
    void createsOrderWithCurrentTimestamp() {
        when(mockRepository.save(any())).thenAnswer(i -> i.getArgument(0));
        
        Order order = orderService.createOrder(new OrderRequest());
        
        assertThat(order.getCreatedAt())
            .isEqualTo(LocalDateTime.of(2026, 3, 22, 10, 0, 0));
    }
}

Prevention: Enable spring.main.allow-circular-references=false (default in Spring Boot 2.6+) to fail fast on circular dependencies during development.

Explore More Articles

Discover more in-depth technical guides on Spring Boot, Java, and software engineering.

Read Full Blog Here

Discussion / Comments

Send Comment

Related Posts