Spring Boot Essentials

What Is Spring Boot?

18 min Lesson 1 of 13

What Is Spring Boot?

If you have worked through the Spring IoC and dependency injection lessons in this course you already know the power of the Spring Framework: a mature, battle-tested ecosystem for building Java applications. You also know the cost — XML files, dozens of bean declarations, component-scan tuning, transaction manager wiring, and a dispiriting amount of time spent before your application even says "Hello". Spring Boot was created to eliminate exactly that cost.

In this lesson you will understand what Spring Boot actually is (and is not), how it relates to the Spring Framework you already know, and why the design philosophy of convention over configuration lets you move from a blank project to a production-capable application in minutes rather than hours.

Spring Boot Is Not a Replacement for Spring

This is the most important mental model to establish first. Spring Boot is not a separate framework and it does not replace any Spring component. It is a set of opinionated defaults, build-time tooling, and runtime infrastructure that sits on top of the Spring Framework and its ecosystem (Spring MVC, Spring Data, Spring Security, etc.).

Every annotation you learned — @Component, @Service, @Autowired, @Transactional — works identically in a Spring Boot application because underneath it is still the same Spring ApplicationContext managing your beans. What Boot adds is a layer that decides how to configure those components so you do not have to.

Key mental model: Spring Framework = the engine. Spring Boot = the car factory that assembles the engine, transmission, wheels, and dashboard with sensible defaults so you can drive immediately rather than building from raw parts.

The Problem Spring Boot Solves

To appreciate what Boot gives you, recall what a traditional Spring web application required before Boot existed:

A web.xml deployment descriptor to register the DispatcherServlet.
A Spring XML or @Configuration class to define a DataSource, a PlatformTransactionManager, a ViewResolver, and an EntityManagerFactory.
A servlet container (Tomcat, Jetty) installed separately and configured to deploy your WAR file.
Manual dependency version alignment — ensuring that Spring MVC 5.x was compatible with Hibernate 5.x which required a particular version of the JDBC driver, etc.

None of this configuration expressed anything about your business domain. It was all boilerplate infrastructure ceremony. Spring Boot eliminates it through three interlocking mechanisms: Starters, Auto-Configuration, and the Embedded Server.

Convention Over Configuration

The guiding philosophy is borrowed from Ruby on Rails and reiterated throughout Boot: prefer conventions (sensible defaults) over requiring explicit configuration. If you add a PostgreSQL driver to your classpath, Boot assumes you want a DataSource pointed at localhost:5432 — unless you say otherwise. If you add Spring Security, Boot secures every endpoint — unless you say otherwise. Every convention is an escape hatch: one property or one @Bean override is enough to replace the default.

This is the opposite of a blank-slate framework. With Boot you start from "everything configured" and selectively turn things off or override them, instead of starting from nothing and assembling every piece.

A Minimal Spring Boot 3 Application

Here is the entire source of a working HTTP server in Spring Boot 3. No XML. No external Tomcat installation. No WAR packaging.

// pom.xml parent (one line that imports 200+ managed dependency versions)
// <parent>
//     <groupId>org.springframework.boot</groupId>
//     <artifactId>spring-boot-starter-parent</artifactId>
//     <version>3.3.0</version>
// </parent>

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication          // (1) three annotations in one
@RestController
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);   // (2)
    }

    @GetMapping("/hello")
    public String hello() {
        return "Hello from Spring Boot 3!";
    }
}

Run this with mvn spring-boot:run and you have a live server at http://localhost:8080/hello. Let us trace what happened.

What @SpringBootApplication Does

@SpringBootApplication is a composed annotation — a shorthand for three annotations applied simultaneously:

@SpringBootConfiguration — marks this class as a Spring @Configuration source (equivalent to @Configuration in plain Spring).
@ComponentScan — enables component scanning from the package of the annotated class downward. Any @Component, @Service, @Repository, or @Controller in sub-packages is automatically picked up.
@EnableAutoConfiguration — triggers Boot's auto-configuration machinery: Spring Boot scans the classpath for recognized libraries and wires up sensible defaults for each one.

Package discipline matters: because @ComponentScan starts from the annotated class's package, place your main class in the root package of your project (e.g. com.example.demo). Sub-packages like com.example.demo.web and com.example.demo.service will all be scanned automatically. A class outside that hierarchy will be invisible to Boot.

SpringApplication.run — What Happens at Startup

The call to SpringApplication.run(DemoApplication.class, args) boots the application in a predictable sequence:

Creates a SpringApplication instance and detects the application type (servlet-based, reactive, or neither) from the classpath.
Loads ApplicationContext initializers and listeners (hooks you can use for pre-context customization).
Instantiates the ApplicationContext and runs auto-configuration.
Starts the embedded Tomcat (or Jetty/Undertow) server.
Fires ApplicationReadyEvent — the signal that the application is live and accepting traffic.

The whole sequence typically completes in under two seconds on a modern laptop. Compare that to deploying a WAR to an external application server.

Spring Boot 3 and the Jakarta EE Namespace

One migration detail that matters if you are upgrading older code: Spring Boot 3 is built on Spring Framework 6, which completed the migration from the javax.* namespace to jakarta.*. Annotations like @NotNull now live in jakarta.validation.constraints, the Servlet API is in jakarta.servlet, and JPA annotations are in jakarta.persistence.

javax.* vs jakarta.*: If you copy a code snippet from a pre-Boot-3 tutorial and it imports javax.persistence.Entity or javax.validation.constraints.NotNull, those imports will fail to compile under Spring Boot 3. Replace every javax. prefix with jakarta.. Your IDE can usually do this automatically.

Boot vs Plain Spring — A Side-by-Side View

To make the contrast concrete, here is what wiring a DataSource looks like in each approach:

Plain Spring (manual configuration):

@Configuration
public class DataSourceConfig {

    @Bean
    public DataSource dataSource() {
        HikariConfig cfg = new HikariConfig();
        cfg.setJdbcUrl("jdbc:postgresql://localhost:5432/mydb");
        cfg.setUsername("user");
        cfg.setPassword("pass");
        cfg.setMaximumPoolSize(10);
        return new HikariDataSource(cfg);
    }

    @Bean
    public JdbcTemplate jdbcTemplate(DataSource ds) {
        return new JdbcTemplate(ds);
    }
}

Spring Boot (convention over configuration):

# application.properties — this is the entire "configuration" required
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=user
spring.datasource.password=pass

Boot detects HikariCP on the classpath, reads those three properties, constructs the HikariDataSource, registers it as the primary DataSource bean, and also registers a JdbcTemplate bean backed by it — all automatically. Your application code simply @Autowired a JdbcTemplate and it works.

Summary

Spring Boot is the production-ready assembly layer for the Spring ecosystem. It does not replace Spring; it configures it for you using conventions, so you can focus on business logic from the first line of code. The three pillars — Starters (curated dependency sets), Auto-Configuration (classpath-driven bean wiring), and the Embedded Server (no external container needed) — work together to deliver this promise. In the lessons that follow you will master each pillar in depth, starting with how to create a Spring Boot project and what a starter actually contains.