Let Spring create objects and inject their dependencies.

Bean basics

A bean is an object managed by the Spring container.

A bean definition tells Spring how to create an object. The resulting bean instance can then be injected into another bean. By default, a bean is a singleton within one ApplicationContext and one bean definition; this is not the same as a JVM-wide Singleton-pattern object.

These stereotypes describe roles; @Service and @Repository are specialised forms of @Component.

It helps to separate two things that are often both called “a bean.” A bean definitionis Spring's recipe: type, name, scope and construction information. A bean instance is the actual Java object created from that recipe.

@Service
public class OrderService {
    // Spring registers a bean definition while scanning.
    // During context refresh, it creates the OrderService object.
}

Component scanning does not inject an annotation into the object. It discovers a class, registers a definition, and later creates and wires the object through normal Java constructors.

What makes a bean different?

The Java object is ordinary; container ownership adds behaviour around it.

OrderService service =
        new OrderService(notificationSender);

@Service
public class OrderService {
    public OrderService(NotificationSender notificationSender) {
        // Spring calls this same Java constructor.
    }
}

Both values are instances of the same Java class. The second is a bean because the context owns its creation, dependency resolution, scope and lifecycle. Annotating a class does not prevent manual construction, although a manually created instance is not automatically registered with Spring.

Constructor injection

The constructor makes required dependencies explicit.

package com.example.orders.service;

import org.springframework.stereotype.Service;
import com.example.orders.notification.NotificationSender;

@Service
public class OrderService {
    private final NotificationSender notificationSender;

    public OrderService(NotificationSender notificationSender) {
        this.notificationSender = notificationSender;
    }
}

Spring sees one constructor, resolves its parameters from the context and calls it. @Autowired is unnecessary when a class has a single constructor. The final field prevents the required dependency from being replaced after construction.

OrderService(
    NotificationSender notificationSender
)

// Question Spring asks:
// "Which bean in this context can satisfy NotificationSender?"

Injection is primarily type-based. Spring does not care about the local field name when one unique bean satisfies the type. It first identifies the constructor, then resolves each parameter, then invokes the constructor with those instances.

@Service
public class OrderService {
    @Autowired
    private NotificationSender notificationSender;
}

A normal Java caller can construct this class without setting the field, so the object is temporarily incomplete. The dependency is also absent from the public construction contract. Constructor injection avoids both problems.

Multiple implementations

Matching the type is necessary, but sometimes not sufficient.

If email and SMS beans both implement NotificationSender, an unqualified injection point has two candidates. Spring knows the required type but cannot infer the business decision.

@Component
@Primary
public class EmailNotificationSender implements NotificationSender {
    // ...
}

@Component
@Qualifier("sms")
public class SmsNotificationSender implements NotificationSender {
    // ...
}

public OtpService(
        @Qualifier("sms") NotificationSender notificationSender
) {
    this.notificationSender = notificationSender;
}

• @Primary marks email as the default candidate.
• @Qualifier("sms") explicitly narrows the OTP dependency to SMS.
• An explicit qualifier wins over the primary choice at that injection point.

A parameter name can sometimes act as a fallback when it exactly matches a bean name and parameter-name metadata is present. That is a fragile place to encode a business rule; use a qualifier when the choice matters.

Think of @Primary as the answer to “which candidate should be the general default?” Think of @Qualifieras part of the injection point's requirement: “I need the SMS-flavoured candidate here.”

Bean names and qualifier labels

A default bean name and a semantic qualifier are related but distinct.

@Component
public class EmailNotificationSender { }
// default bean name: emailNotificationSender

@Component
@Qualifier("sms")
public class SmsNotificationSender { }
// default bean name: smsNotificationSender
// qualifier metadata: sms

Spring normally converts the class name to lower camel case for the default bean name. @Qualifier("sms") adds selection metadata; it does not rename the bean to sms. An injection point with the same qualifier selects candidates carrying that label.

@Component("smsSender")
public class SmsNotificationSender
        implements NotificationSender {
}
// explicit bean name: smsSender

Bean-name fallback can occasionally make a parameter named smsNotificationSender resolve successfully. That couples the choice to a local variable name and compiler metadata. For an intentional business distinction such as “OTP must use SMS,” a qualifier communicates the rule directly.

Scope and identity

Default singleton means one instance per definition per context.

@Service
class OrderService {
    OrderService(NotificationSender sender) { /* ... */ }
}

@Service
class ReceiptService {
    ReceiptService(NotificationSender sender) { /* ... */ }
}

// If email is the selected singleton bean, both constructors
// receive the same email bean object in this ApplicationContext.

This is a container scope, not a JVM-wide guarantee. A second ApplicationContext creates its own singleton. Two different bean definitions can also produce two instances of the same Java class.

@Bean
NotificationSender customerEmailSender() {
    return new EmailNotificationSender();
}

@Bean
NotificationSender operationsEmailSender() {
    return new EmailNotificationSender();
}

Run code after startup

CommandLineRunner is itself a bean.

Boot calls every CommandLineRunner after the context has started. A runner is useful for this non-web learning application because it lets us exercise injected services without manually asking the context for them.

EmailNotificationSender
        ↓ injected into
OrderService
        ↓ injected into
DemoRunner
        ↓ invoked by Boot after startup

If any arrow cannot be resolved, the context fails before DemoRunner.run is called. That fail-fast behaviour keeps an application from accepting work with an incomplete object graph.