Spring Boot Course
History of Spring
- Spring was originally named Interface21 and was introduced by Rod Johnson in 2002 as an alternative to the heavyweight EJB (Enterprise JavaBeans) model. The name "Spring" reflected a fresh start for Java enterprise development.
- Spring is maintained by VMware Tanzu (formerly Pivotal, which was itself spun out of EMC/Dell and later reacquired by Broadcom). Saying it is "maintained by spring.org" is inaccurate — spring.io is the project website, not the owning organization.
- Spring emerged as an alternative to EJB because EJB required an application server (JBoss, WebLogic, WebSphere), was tightly coupled to that server, was difficult to test outside of it, and was notoriously verbose and error-prone to configure.
- Spring is lightweight in that it doesn't require a full Java EE application server — it runs on a plain JVM with just a Servlet container (Tomcat, Jetty, etc.) or even as a standalone process (as of Spring Boot with embedded containers).
- Spring is non-invasive: your classes don't need to extend Spring classes or implement Spring interfaces (unlike Struts, which required actions to extend
Action, or EJB, which required component classes to implement container interfaces). Your business logic stays clean. - Spring is built on two core principles: Inversion of Control (IoC) / Dependency Injection, and Aspect-Oriented Programming (AOP). It is not simply "runtime polymorphism and Has-A relationship" — that phrasing is too narrow. IoC means the Spring container controls the creation and lifecycle of objects (beans) and injects their dependencies, rather than your code calling
newdirectly.
Framework: A software foundation that provides structure, conventions, and reusable libraries to simplify building an application in a specific domain. Frameworks are "semi-finished" software you extend and configure — unlike libraries, which you call.
Invasive framework: Requires you to extend framework-provided base classes or implement framework-provided interfaces. Struts 1.x (extend Action), older EJB (implement SessionBean) — your domain classes become tightly coupled to the framework.
Non-invasive framework: Does not require your business classes to extend or implement anything framework-specific. Spring (POJO-based DI), Hibernate (POJO + JPA annotations, but no mandatory base class), and JPA are all non-invasive.
EJB promised scalability, security, and high availability, but in practice:
- Required enormous configuration boilerplate (XML descriptors, stub/skeleton generation, deployment units)
- Was error-prone and slow to develop against
- Was tightly coupled to the application server, making unit testing nearly impossible
- Restart cycles on enterprise app servers (JBoss, WebLogic) were measured in minutes, killing developer productivity
Spring Modules

Spring is a family of projects, not a single framework. The core modules include:
- Spring Core / Spring Context: IoC container, dependency injection, bean lifecycle management
- Spring MVC: Web framework for building REST APIs and traditional web applications
- Spring Data: Abstraction over JPA, JDBC, MongoDB, Redis, and other data stores
- Spring Security: Authentication, authorization, OAuth2, JWT
- Spring AOP: Aspect-Oriented Programming support
- Spring Batch: Framework for large-scale batch processing
- Spring Integration: Enterprise integration patterns (messaging, adapters)
- Spring Cloud: Distributed systems and microservices tooling
What is Spring Boot?
Spring Boot is an extension of the Spring Framework that eliminates the boilerplate configuration required to set up a Spring application. It applies convention over configuration — pre-configuring the most common Spring setup so you can get a production-ready application running in minutes rather than days.
Spring Boot is NOT a replacement for Spring — it's Spring, with opinions applied. Everything Spring Boot does, you could do manually in plain Spring; Spring Boot just does it for you automatically based on what's on the classpath.
Features of Spring Boot
- Creates stand-alone Spring applications packaged as a single executable JAR (fat/uber JAR) or WAR.
- Embeds an HTTP server (Tomcat by default, optionally Jetty or Undertow) so no separate server installation or deployment is needed.

- Provides opinionated "starter" dependencies (
spring-boot-starter-web,spring-boot-starter-data-jpa, etc.) that pull in a curated, compatible set of dependencies — no more dependency version conflicts. - Automatically configures Spring and third-party libraries based on classpath detection using
@ConditionalOn*annotations (@ConditionalOnClass,@ConditionalOnBean,@ConditionalOnMissingBean, etc.). - Provides production-ready observability:
/actuator/health,/actuator/metrics,/actuator/info, and integration with Micrometer for metrics export to Prometheus, Datadog, CloudWatch, etc. - Zero code generation and no required XML configuration. Everything can be done with Java annotations and
application.yml/application.properties.
Spring vs. Spring Boot

Spring (Framework)
- Dependency Injection and IoC container
- Manages the lifecycle of application components (beans)
- Requires explicit, manual configuration (either XML or
@Configurationclasses) - Takes significant boilerplate to get even a simple web application running
Spring Boot
- Dependency Resolution: starter POMs bring in compatible dependency sets with no version guessing
- Auto-configuration: scans the classpath and wires sensible defaults automatically
- Embedded server: no external application server to install, configure, or manage
- Bean auto-scan: components in your package hierarchy are discovered automatically
- Production-ready observability via Actuator
- First-class support for microservices patterns and cloud-native deployment
- Opinionated integration with the broader Spring ecosystem (Spring Data, Spring Security, Spring Cloud)
A useful summary: Spring Boot = Spring Framework + Auto-configuration + Embedded Server + Opinionated Defaults. The old "Spring Boot is (Spring Framework - XML Configuration) + Integrated server" is an oversimplification that misses auto-configuration, which is the real value.
What Spring Boot is NOT
- It does not generate code at build time (unlike Quarkus with compile-time DI, or frameworks like Micronaut).
- It is not an application server or web server itself — it embeds one, but the embedded Tomcat/Jetty/Undertow is just a library inside the JAR, not a standalone server.
Why is it "opinionated"?
Convention over configuration — Spring Boot makes reasonable default choices (Tomcat for the web server, Hibernate for JPA, HikariCP for connection pooling, Logback for logging) based on what's on the classpath. You can override any of these defaults, but you don't have to specify them if the defaults suit your needs. The fewer decisions you have to make to get started, the faster you move.
How does Auto-configuration Work?
Spring Boot uses @EnableAutoConfiguration (included via @SpringBootApplication) which triggers the auto-configuration mechanism. Spring Boot reads a list of candidate auto-configuration classes from META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Spring Boot 2.7+; previously spring.factories). Each candidate class is conditionally applied based on annotations like:
@ConditionalOnClass: Apply this config only if a specific class is present on the classpath. Example: configure aDataSourceonly if Hikari and JDBC are present.@ConditionalOnMissingBean: Apply this config only if no bean of this type has been manually registered. This is what lets you override auto-configuration with your own bean.@ConditionalOnBean: Apply only if another specific bean is already registered.@ConditionalOnProperty: Apply only if a specific property is set (or has a specific value) inapplication.yml.
This is how Spring Boot "knows" what to configure: it doesn't scan your code at startup and guess — it follows a deterministic set of conditions. You can see exactly what was auto-configured (and what wasn't, and why) via /actuator/conditions.
