Learn Spring Boot - History, Background & Why You Need Spring Boot

#Introduction

Before Spring Boot existed, building web applications with Java was a very painful experience. In episode 1 we step back for a moment to look at the history and background of why Spring Boot was born, and the concrete problems it solves.

Understanding this history isn't just nostalgia. When you understand the root problems that gave rise to auto-configuration and starter dependencies, you'll find it easier to predict how Spring Boot behaves — and when to override its default behavior. This is a mental foundation that's extremely useful throughout the entire series.

#The Evolution of the Spring Framework

#From Introduction to the Manual Configuration Problem

The Spring Framework was born in 2002 as an answer to the complexity of Enterprise JavaBeans (EJB). Spring introduced the concepts we now know as dependency injection and Inversion of Control, turning Java components into simple POJOs. However, in its early days, all configuration was done through XML files that were very long and hard to maintain.

Imagine declaring every bean, the relationships between beans, transactions, and security in one giant XML file:

<beans xmlns="http://www.springframework.org/schema/beans">
    <bean id="itemRepository" class="com.example.ItemRepository"/>
    <bean id="itemService" class="com.example.ItemService">
        <property name="repository" ref="itemRepository"/>
    </bean>
    <bean id="itemController" class="com.example.ItemController">
        <property name="service" ref="itemService"/>
    </bean>
</beans>

Every time you added a new class, you had to remember to register it here. Forget once, and the application failed at runtime. This is what's called configuration boilerplate — routine work that has nothing to do with business logic.

#From XML to Annotations and Auto-Configuration

Spring 2.5 began introducing annotation-based configuration such as @Component and @Autowired. Spring 3 added Java configuration with @Configuration and @Bean. Each iteration reduced the amount of XML you had to write. However, integrating other technologies — databases, message queues, web servers — still demanded consistent manual configuration that was easy to get wrong.

The genesis of Spring Boot happened in 2012, when Spring developers realized that the entire framework pipeline — bean creation, datasource configuration, web server setup — always repeated itself from project to project. From that realization, the concept of auto-configuration was born: Spring looks at what libraries are on the classpath, then automatically prepares sensible configuration.

#Problems Solved by Spring Boot

#Minimal Boilerplate and Consistent Dependency Management

Spring Boot removes almost all of the manual configuration work. Take starter dependencies — dependency bundles that Spring has already selected for your needs. A single spring-boot-starter-web dependency pulls in all the libraries needed for a web application: Spring MVC, Jackson, and embedded Tomcat.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'com.h2database:h2'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

Notice: no version numbers are written manually. Spring Boot uses built-in dependency management so the version of every library is agreed upon and tested together — this eliminates one of the classic sources of problems in Java known as dependency hell, i.e. version conflicts between libraries.

#Embedded Server and Rapid Development

Before Spring Boot, running an application meant installing Apache Tomcat, deploying a WAR file, and starting the server manually. Spring Boot flips this concept: Tomcat, Jetty, or Undertow are embedded directly into the application, and the application runs simply by calling the main method. The result is rapid development — one command to run, one command to test.

./mvnw spring-boot:run

The ./mvnw spring-boot:run command starts the embedded Tomcat, runs auto-configuration, and makes the application ready to accept requests within seconds. For production, the application is packaged as an executable jar that can be run with java -jar on any server with a JVM:

./mvnw clean package
java -jar target/belajar-spring-boot-0.0.1-SNAPSHOT.jar

With this single artifact, the application runs on a server, in a container, or in a CI environment without any additional installation.

#Comparison with the Traditional Approach

To make Spring Boot's value clearer, compare the journey of building a simple web application with two approaches:

• Classic Java EE: writing lots of configuration, installing an external application server, deploying WARs manually, and managing dependencies that are prone to version conflicts.
• Pure Spring MVC: better than Java EE, but still requiring XML or Java config setup for web, datasource, and transaction manager.
• Spring Boot: starter dependencies, auto-configuration, embedded server, actuator, and profiling ready to use in one battle-tested ecosystem.

The most obvious differences are in onboarding and consistency. With Spring Boot, new developers can run their first application within minutes, and every project follows the same pattern because they're all generated from Spring Initializr.

The same habits apply across teams and libraries, so moving between Spring Boot projects feels familiar. With its massive ecosystem — hundreds of starters and polished official documentation — the learning curve stays gentle even as features keep growing.

#Spring Boot's Position in the Modern Ecosystem

Today Spring Boot is the de facto standard for Java backend, especially in the cloud-native era. With lightweight container support, fast-running auto-configuration, and the Spring Cloud ecosystem for distributed systems, Spring Boot has become the primary choice for building microservices. The latest releases in the Spring Boot 3.x line run on Spring Framework 6, require Java 17 and above, and support observability and native images — all topics we'll cover in the later episodes of this series.

XML config -> Annotation -> Java config -> Spring Boot 3.x

This ecosystem is also broad: Spring Data for persistence, Spring Security for authentication, Spring Cloud for microservices, and Spring Reactive for non-blocking applications. Each one will be explored in the relevant episodes.

#Closing

Episode 1 provided the historical context and motivation behind Spring Boot: the framework was born to remove configuration boilerplate, unify dependency management, and accelerate Java application development with an embedded server and auto-configuration.

Key takeaways:

• Spring Boot was born from frustration with complex, repetitive Spring XML configuration.
• Auto-configuration reads the classpath and prepares sensible configuration automatically.
• Starter dependencies manage library versions consistently without writing manual version numbers.
• The embedded server lets you run the application with just ./mvnw spring-boot:run.
• Spring Boot 3.x runs on Java 17 and above and supports cloud-native development.
• The Spring Data, Security, and Cloud ecosystems complete Spring Boot as a full platform.

In the next episode, episode 2, we'll discuss core concepts and key architecture — how it works behind the scenes: the application lifecycle, the auto-configuration mechanism with conditional beans, the role of @SpringBootApplication, the application context, DispatcherServlet, and application profiles. This is where you begin to see how Spring Boot works from the inside.