Every Spring Boot application has exactly one class marked with @SpringBootApplication, usually the one containing the main method. It looks like a single simple annotation, but it is actually doing three separate jobs at once, and understanding each of them removes a lot of the mystery around how a Spring Boot app starts.

It is three annotations in one

Placing @SpringBootApplication on a class has exactly the same effect as stacking these three annotations together:

  • @Configuration marks the class as a source of bean definitions, meaning it is allowed to declare objects that Spring should manage.
  • @EnableAutoConfiguration turns on Spring Boot's automatic setup, which inspects the libraries on the classpath and configures matching features, such as a web server appearing once Spring Web is added.
  • @ComponentScan tells Spring to look through the current package, and every package below it, searching for classes annotated with things like @Component, @Service, @Repository and @RestController, so they can be registered and managed automatically.

A typical main class

@SpringBootApplication
public class MyApp {
  public static void main(String[] args) {
    SpringApplication.run(MyApp.class, args);
  }
}

The run method does the real work: it creates the Spring application context, triggers component scanning and auto-configuration, and starts the embedded server if a web starter is present. Everything else in the application builds on top of the context this single line creates.

Why package placement matters

Because @ComponentScan only looks in the current package and its sub-packages, the class carrying @SpringBootApplication should sit at the top level of the project's package structure, for example com.example.demo, with controllers, services and repositories organised in packages beneath it. A class placed in a sibling package that component scanning cannot reach will simply be invisible to Spring, which is one of the most common causes of a confusing missing-bean error for beginners.

Overriding auto-configuration when needed

Auto-configuration makes sensible guesses, but it always steps aside if a bean of the same type is defined explicitly. For example, if a custom DataSource bean is declared, Spring Boot's automatic database configuration backs off and uses that one instead. This override-friendly design is what makes auto-configuration safe to rely on: it saves effort in the common case without locking a project into defaults it cannot escape.

The takeaway

This class is rarely edited after it is created. What matters is knowing that its single annotation is responsible for turning on scanning, auto-configuration and the ability to define beans, which together explain why a Spring Boot application can do so much while the developer writes comparatively little code.