What happens internally in running a Spring Boot application?

In general, Spring Boot is concerned with 3 main things at startup:

1) Automatically configure your project from the dependencies you declare in the build system (pom.xml - Maven or build.gradle - Gradle) on which your project is built. This is done by the annotation @EnableAutoConfiguration .

2) Scrub your project for classes that have certain specific annotations (such as @Service or @Repository , for example), which state that these classes must have their Spring managed life cycle. These classes are beans and the fruit of this management is nothing more than the dependency injection (the @Autowired you have certainly seen). Sweeping is triggered by the annotation @ComponentScan .

3) Define that the class itself containing the main method is itself a bean , annotating it with @Configuration . Because? To allow you to have other beans (already previously scanned by item 2) injected into that class, saving you from the need to create additional classes for this. Remembering that only a bean class (that is, managed by Spring) may have injected into it other beans .

Well, for convenience, instead of annotating your class with all 3 annotations in bold, you just have to write it down with @SpringBootApplication , which will have the same effect with the default settings of Spring Boot.

Extending your question a little: but, why is the main() method? To allow your application to run as a common Java application, which, as we know, is started from a main() method. Since a Spring Boot program has its own servlet container (Tomcat by default) and everything it needs to "deploy itself and boot itself", just one entry point (method main() ) for it to run.

It is different from an application made in Spring MVC, for example, in which you need to indicate an external Tomcat (and that is already pre-installed), start this container yourself and then run your application. Not to mention all the "on-the-fly" configuration you'll need to make to make your project functional.

And then you ask, but why does not Spring MVC follow this same concept of initialization?

The first point is that Spring MVC is an implementation of the Java EE Servlet API (interface for web systems) with (many) advantages and facilities for development. And any Servlet API implementation needs an application server (Tomcat, JBoss, Glassfish, etc.) to run, with all the "bureaucracy" of configuration and initialization involved.

The second point is that, underneath the cloths, Spring Boot has the Spring MVC (after all, the Boot remains a web-system development framework), but with the "automated bureaucracy" as much as possible.

But here comes the big one, Spring Boot was thought of already taking into account the distributed microstructure, in other words, small self-executing systems (see the need for the main() method there) and scalable ones that should be independent centralized application server to be run, started, "killed" when needed, overwritten and redeployed. This kind of micro-service, in fact, should behave as a stand-alone, self-sufficient desktop application with the least amount of external dependency possible. These features are not found in a Spring MVC project, but they have made Spring Boot so popular and so widely used around the world.