@Component

What @Component Means in Spring

@Component is part of Spring’s stereotype model: it marks a class as a managed bean candidate so component scanning can discover it and register it in the application context. That makes the class part of the container’s dependency graph rather than an ordinary Java object created manually by the application.

How Component Scanning Uses It

When Spring scans configured packages, it looks for stereotype annotations and turns matched classes into beans. @Component is the base stereotype, while other annotations such as @Service, @Repository, and @Controller are specialised forms that exist to communicate intent more clearly without changing the underlying bean registration mechanism.

That distinction matters because the annotation is about container management, not business logic. A class annotated with @Component may still be simple or complex, but its lifecycle, instantiation, and dependency injection are now controlled by Spring rather than by direct constructor calls or manual factory code.

Why It Matters for Application Design

@Component is often the smallest unit of Spring-managed structure, so it shapes how code is assembled, tested, and reasoned about. Once a class is container-managed, dependencies can be injected consistently, cross-cutting concerns can be applied through the framework, and object creation becomes a governed part of application startup instead of scattered across the codebase.

That also means placement and package structure matter. If component scanning does not reach a class, Spring will not create it as a bean, and any downstream injection points that expect it can fail at runtime or during context initialisation.

Common Misunderstandings

A frequent mistake is treating @Component as a generic “make this class available” flag. In practice, it only works within Spring’s scanning and configuration model, so the annotation is effective only when the application context is set up to discover it. Another common misunderstanding is assuming that all stereotype annotations are materially different; most of the time they differ mainly in semantic clarity, not in the core bean-registration mechanism.

Another subtle point is that @Component does not by itself define scope, transactionality, persistence behaviour, or web exposure. Those concerns come from other annotations, framework conventions, or explicit configuration layered on top of the bean lifecycle that @Component enables.

Related resources from NHI Mgmt Group

• What breaks when a GitHub Actions workflow component is compromised?
• What is the difference between identity infrastructure and a login component?
• What breaks when sensitive data is passed from a Server Component to a Client Component?
• What is the main risk of giving AI access to component hierarchies and style mappings?