Spring Boot Starters: What Each One Bundles

Before Spring Boot, starting a web project meant a painful ritual: find the right version of Spring MVC, a compatible Jackson, a matching validation library, then pray they did not clash at runtime. Starters replace that ritual with a single line. This tutorial explains what a starter really is, what the common ones bundle, and why you almost never think about versions again.

What a starter actually is

A starter is not a big library. Open one and you find it contains almost no code — it is a small module whose entire job is to declare a curated list of other dependencies. When you add a starter, your build tool pulls in every library it points to. So one entry expands into a compatible, tested set.

The naming is consistent: official starters follow the pattern spring-boot-starter-*. The suffix tells you the purpose — web, data-jpa, validation, test, security. This predictability is part of why Spring Boot is comfortable to work in: you can usually guess the starter name for a feature before looking it up.

Adding a starter in your build file

In Maven, a starter is a single dependency with no version:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>
</dependencies>

Notice there are no <version> tags. That works because your project inherits from spring-boot-starter-parent, which supplies a managed version for every Spring Boot library. Boot picks a set of versions that have been tested together, so you get compatibility for free. In Gradle the same idea uses the dependency management plugin.

Pro tip: Never add explicit versions to Spring Boot starters unless you have a very specific reason. Overriding one version by hand is the single most common cause of the mysterious NoSuchMethodError at startup, because you have broken the tested version set.

What the common starters bundle

Here is what you actually get from the starters you will use most:

The web starter is where most projects begin because a single line gives you a runnable HTTP server. The data-jpa starter is the foundation for the Spring Data JPA work you will do once your API needs persistence.

Why one line is enough to run a server

Adding spring-boot-starter-web and nothing else produces a working application:

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
@RestController
public class PingApp {

    @GetMapping("/ping")
    public String ping() {
        return "pong";
    }

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

Run it and you have an HTTP server on port 8080 returning pong. You never configured Tomcat, registered a dispatcher servlet, or set up JSON conversion. That is because the starter put those libraries on the classpath and auto-configuration detected them and wired the beans. Starters and auto-configuration are two halves of the same mechanism: the starter supplies ingredients, auto-configuration assembles them.

Reading what a starter dragged in

When you need to see the full set of libraries a starter added — for a security audit or to debug a version clash — ask your build tool for the dependency tree:

## Maven
mvn dependency:tree

## Gradle
./gradlew dependencies

The output shows the starter at the top and everything it pulled in beneath it, transitively. This is invaluable when two starters both bring in the same library at different versions and you need to understand which one won. It is also the honest answer to "what does starter-web contain" — read the tree rather than trusting memory.

Common mistake: Adding both spring-boot-starter-web and a separate, hand-picked Tomcat or Jackson dependency. The starter already includes them. Duplicating them at a different version reintroduces exactly the conflict starters were designed to eliminate.

Building on the foundation

Once the right starters are in place, the rest of your first application is just code — controllers, services and entities. If you are assembling your very first project, walk through the Spring Boot first application tutorial, which uses the web starter as its base. As your app grows you add starters incrementally: validation when you start checking inputs, data-jpa when you add a database, security when you add login. Each one is a single, version-managed line.

Custom starters are the natural next step for teams. A shared library can package its own dependencies plus an auto-configuration class into a starter, so every other team gets preconfigured beans by adding one dependency — the same pattern the official starters follow.

How version management actually works

The reason you can omit versions deserves a closer look, because it is the feature that saves the most time. Two mechanisms are at play. spring-boot-starter-parent sets your project's parent POM, and that parent declares a dependencyManagement section pinning a compatible version for hundreds of libraries. When you add a starter without a version, Maven resolves it against that pinned set.

If you cannot use the starter-parent — common when your organisation already mandates a corporate parent POM — you import the Spring Boot Bill of Materials (BOM) instead:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>3.3.2</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

This imports the same managed versions without changing your parent. Either way, the outcome is the same: one place decides versions, and every starter obeys it. That is what "just works" actually means underneath.

Troubleshooting starter problems

Two problems account for most starter-related headaches. The first is a version clash, where a non-Spring library you added pulls in a different version of something a starter also uses. The dependency:tree output shows the conflict, and the fix is usually to let Boot's managed version win by removing your explicit version. The second is a missing starter, where a feature silently does nothing because its library is absent — the classic case being validation constraints ignored until you add spring-boot-starter-validation.

Interview note: A sharp follow-up is "what happens if you override a starter's managed version?" The honest answer is that you take on the risk of an untested combination. Sometimes it is necessary, for a security patch ahead of a Boot release, but you do it knowingly, not by habit — and you test carefully afterwards.

Once your starters are settled, the day-to-day work moves to writing controllers, services and entities. The starters fade into the background, quietly guaranteeing that the libraries beneath your code are a matched set. That is exactly the point: you should be thinking about your domain, not about whether Jackson 2.15 works with this Spring MVC version.

Interview relevance

Starters come up as a warm-up question and as a gateway to deeper topics. Be ready to explain that a starter is a curated dependency bundle rather than a library, name what spring-boot-starter-web contains, and describe how the starter-parent manages versions so you omit them. The strong follow-up answer connects starters to auto-configuration: the starter adds libraries, and auto-configuration reacts to them. Rehearse these alongside the Spring Boot fresher interview questions, where "what is a starter" and "what is auto-configuration" are usually asked back to back.