Introduction to Spring Boot

Section 2Detailed Study Notes#

Picture your first week on a Java team in 2010. Before you write a single line that does anything a user cares about, you're editing three XML files to tell the framework which objects to build, downloading a Tomcat server and pointing your project at it, and chasing a version conflict between two libraries that refuse to agree. A day gone, and the app still just prints "hello." That friction — real, daily, and universal — is the entire reason Spring Boot exists. This lesson is the story of how Java web development stopped feeling like assembling furniture with no instructions.

2.1The problem: Java web development used to be mostly setup#

Before frameworks, building a serious Java application meant hand-wiring an enormous amount of plumbing before any real work began. A team spent its early days on four recurring chores, none of which delivered a feature:

• Complex configuration. Behaviour lived in XML files and repetitive boilerplate, not in readable code.
• Time-consuming setup. Servers, dependencies, and frameworks all had to be configured by hand before anything ran.
• Deployment headaches. The app had to be packaged and shipped to a separate server that someone else configured and maintained.
• Maintenance drag. As a project grew, keeping dependencies and configuration coherent became its own full-time tax.

Every one of these stole time from the actual product. Two engineers, Rod Johnson and Juergen Hoeller, wrote the Spring Framework to take that weight off developers. [+] Spring first appeared in 2003; the deck introduces it as the direct answer to this pain.

2.2Spring: the problem solver — and its catch#

Spring is a framework that takes over the tedious lifecycle work of creating and connecting your objects, so your code can focus on behaviour. It did the heavy lifting through two ideas that sit at its core, plus a set of ready-made infrastructure layers.

Inversion of Control (IoC)#

Normally your code is in charge: when it needs a helper object, it builds that object itself with new. Inversion of Control flips that — the framework, not your code, is in charge of creating and owning objects. You describe what should exist; Spring builds it, holds it, and hands it over when needed. The "control" over object lifecycle has been inverted from you to the framework.

Dependency Injection (DI)#

Dependency Injection is the delivery mechanism for IoC: instead of an object fetching the things it depends on, those things are handed to it from the outside. If your OrderService needs a PaymentClient, you don't build the client inside the service — you declare that you need one, and Spring injects a ready-made instance. The two terms travel together: IoC is the principle, DI is how Spring does it.

The catch. Spring gave excellent features and fine-grained control, but that control came at a price. As projects grew, the deck names three fresh pains that Spring alone didn't solve:

• Complex project setup — multiple configuration files, manual dependency management, and version-compatibility issues between libraries.
• Server configuration — you still set up an external server (Tomcat, Jetty, …) by hand and deployed a WAR file to it.
• Integration challenges — stitching multiple frameworks together, on top of a complex build process.

These are what "paved the way" for Spring Boot in 2014.

2.3Spring Boot: Spring with the assumptions made for you#

Spring Boot is a layer built on top of Spring that removes the setup by taking an "opinionated" view — it makes reasonable assumptions about what most developers need and configures them automatically. You still get all of Spring underneath; you just stop paying the setup tax to reach it.

"Opinionated" is the key word. It means Boot ships with sensible defaults already chosen — a default server, default configuration, default project layout — so you can run immediately. Crucially these are defaults, not walls: you can override any of them when your case is unusual.

2.4Spring vs Spring Boot, side by side#

The deck presents this contrast as its own overview slide. The distinction is about who does the configuring.

2.5Starting a project: Spring Initializr#

Spring Initializr is a web tool from the Spring team that generates a ready-to-run project skeleton for you. You describe the project in a form; it hands back a zip with the folder structure, the build file, and your chosen dependencies already wired in. It lives at start.spring.io↗.

It exists so that "start a new Spring Boot project" doesn't mean "hand-assemble a build file and a directory tree from memory." You pick your options and the correct, version-compatible skeleton is generated for you — the same convention-over-configuration philosophy, applied to the very first step.

What you choose on the form#

2.6Your first controller: Hello World#

A controller is the class that receives incoming web requests and decides what to send back. It's the front door of your application: a URL arrives, the controller matches it to a method, the method runs, and its return value becomes the response. The Hello World exercise builds exactly one.

The workflow from the deck: create a class such as HelloWorldController under src/main/java/..., paste the controller code and resolve imports, run ./gradlew bootRun in the terminal, then visit the endpoint in a browser with a query parameter attached.

@RestController
public class HelloWorldController {

    @GetMapping("/helloworld")
    public String getMethodName(@RequestParam String name) {
        return new String("Hello World, I am " + name + "!");
    }
}

Three annotations do all the work here. Read plainly, before the jargon:

• The "answer-with-data" marker (@RestController) tells Spring this class handles web requests and that whatever a method returns should be written straight into the HTTP response body — no separate view or template step.
• The "when this URL is GET-ed" marker (@GetMapping("/helloworld")) maps an HTTP GET request on /helloworld to this method. Visit that path and this method runs.
• The "read a value from the URL" marker (@RequestParam) pulls a value out of the query string — the ?name=Groot part — and hands it to the method as the name argument.

So a request to http://localhost:8080/helloworld?name=Groot runs the method with name = "Groot" and returns the text Hello World, I am Groot! straight to the browser. [!] The deck's screenshot text shows the placeholder name as both "Goot" and "Groot"; the intended name is Groot — the "Goot" is a slide typo.

2.7What comes next (agenda roadmap)#

The session agenda continues past this point; the following were listed but not present in the captured slides. Treat this as a map of where the lesson heads, not as taught material. [!]

2.8Interview & practice questions#

The natural follow-ups this material invites. Answer each aloud before expanding it.

2.9Key takeaways#

1. Traditional Java development lost days to configuration, manual servers, and dependency conflicts before any feature got written.
2. Spring (Rod Johnson & Juergen Hoeller) solved much of this through Inversion of Control and Dependency Injection, but still demanded heavy setup of its own.
3. Spring Boot (2014) is Spring made opinionated: auto-configuration, an embedded server, dependency starters, and production-ready Actuator features.
4. Spring Boot doesn't replace Spring — it's a convenience layer on top of it. That relationship is the most common interview trap.
5. Spring Initializr at start.spring.io generates a runnable project skeleton so you never hand-assemble the first setup.
6. A controller is your app's front door: @RestController returns data as the response body, @GetMapping routes a URL, @RequestParam reads the query string.

Section 3Microexercises — Build the Muscle#

Spring Boot's whole promise is that you write business code on day one. So the practice is writing controllers, not reading about them. Attempt each drill before opening the walkthrough — type the controller, predict the error — then check yourself. Muscle memory beats recognition.

EX 1Extend the controller: an optional parameter with a default#

@RestController
public class GreetController {

    @GetMapping("/greet")
    public String greet(@RequestParam String name, @RequestParam(defaultValue = "en") String lang) {

        String hello = switch (lang) {
            case "es" -> "¡Hola";
            case "hi" -> "नमस्ते";
            default   -> "Hello";
        };
        return hello + ", " + name + "!";
    }
}

EX 2Diagnose two "why won't it work" moments#

Symptom 1 — the wrong base annotation. Hitting /status gives a 500 / "Whitelabel Error Page" / "template not found" instead of the text OK.

@Controller                       // ← note: not @RestController
public class StatusController {

    @GetMapping("/status")
    public String status() {
        return "OK";
    }
}

Symptom 2 — the app fails to start with:

Web server failed to start. Port 8080 was already in use.

@RestController                   // ← now the return value IS the body
public class StatusController {

    @GetMapping("/status")
    public String status() {
        return "OK";
    }
}