Spring Boot Starters: What They Do and How to Build One
Fast recall
Quick revision
Core answer
spring-boot-dependencies and auto-configuration classes listed in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Spring Boot 2.7+). To build a custom starter, you create two modules: *-spring-boot-autoconfigure (contains @AutoConfiguration classes with @ConditionalOn* guards and @ConfigurationProperties) and *-spring-boot-starter (the empty 'marketing' artifact that consumers add). Conditionals ensure safe behavior when optional libs are absent and let users override defaults.Understanding of Boot's auto-config mechanism, starter/BOM split, conditional beans, and the structure of a custom starter
Thinking starters contain code, not knowing the autoconfigure vs starter module split, and forgetting `@ConditionalOnMissingBean` so user overrides are silently ignored
Discuss the `AutoConfiguration.imports` file (Boot 2.7+ format), `@ConditionalOnMissingBean`, `@AutoConfigureBefore`/`After`, and testing with `ApplicationContextRunner`
Interview-ready guide
Interview answer
A Spring Boot Starter is an opinionated dependency descriptor — an essentially empty Maven or Gradle artifact that pulls in a curated, version-aligned set of transitive dependencies plus auto-configuration that wires sensible defaults.
The three roles of a starter
- Dependency grouping —
spring-boot-starter-webbrings Spring MVC, Jackson, Tomcat, validation - Version alignment — the
spring-boot-dependenciesBOM pins all transitive versions to a tested combination - Auto-configuration — starters pull autoconfigure JARs that activate when classes and beans are detected
How auto-configuration fires
@SpringBootApplicationtriggers@EnableAutoConfiguration- Spring scans
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports(Boot 2.7+) - Each listed class becomes a candidate; activates only if
@ConditionalOn*guards pass - Common conditionals:
@ConditionalOnClass,@ConditionalOnMissingBean,@ConditionalOnProperty,@ConditionalOnWebApplication - Ordering via
@AutoConfigureBefore,@AutoConfigureAfter,@AutoConfigureOrder
Building a custom starter — the two-module pattern
*-spring-boot-autoconfigure: contains@AutoConfigurationclasses,@ConfigurationProperties, and theAutoConfiguration.importsfile*-spring-boot-starter: empty POM that depends on the core library plus the autoconfigure module- Consumer adds the starter; conditionals ensure the auto-config activates only when appropriate and steps aside when the consumer defines their own bean
Best practices for starter authors
- Always
@ConditionalOnMissingBeanon beans the consumer might override - Use
@ConditionalOnClassto guard against missing optional libraries @ConditionalOnProperty(matchIfMissing = true)for on-by-default opt-out features- One
@AutoConfigurationper feature area (main wiring, metrics, health, security) - Pair
@ConfigurationPropertieswithspring-boot-configuration-processorfor IDE auto-completion - Test with
ApplicationContextRunner— no full Boot context needed, super fast
Debugging a missing bean
- Enable
logging.level.org.springframework.boot.autoconfigure=DEBUGor hit/actuator/conditions - Look at the negative matches section — usually
@ConditionalOnClassfailed, a property is missing, or a bean is already defined
Format change to know
- Boot ≤ 2.6:
META-INF/spring.factorieswith theEnableAutoConfigurationkey - Boot 2.7+:
META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports - Boot 3.x: same file;
@Configurationdeprecated for auto-configs in favor of@AutoConfiguration
In an interview, the strong answer is: starters are empty POMs that aggregate dependencies and trigger auto-configuration; a custom starter is two modules — autoconfigure for the code, starter for the empty aggregator — with `@ConditionalOn*` guards that always let consumers override.
Spring Boot Starters: What They Do and How to Build One
Direct Answer
A Spring Boot Starter is an opinionated dependency descriptor — an essentially empty Maven/Gradle artifact that pulls in a curated, version-aligned set of transitive dependencies plus auto-configuration that wires sensible defaults. Internally, starters rely on two mechanisms: BOM-managed versions via spring-boot-dependencies and auto-configuration classes listed in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Spring Boot 2.7+). To build a custom starter, you create two modules: *-spring-boot-autoconfigure (contains @AutoConfiguration classes with @ConditionalOn* guards and @ConfigurationProperties) and *-spring-boot-starter (the empty 'marketing' artifact that consumers add). Conditionals ensure safe behavior when optional libs are absent and let users override defaults.
Common Mistakes & Pitfalls
Thinking starters contain code, not knowing the autoconfigure vs starter module split, and forgetting @ConditionalOnMissingBean so user overrides are silently ignored
Check your understanding
Answer these without looking back at the article.
- Why does Spring Boot 2.7+ use `AutoConfiguration.imports` instead of `spring.factories`?
- How does `@ConditionalOnMissingBean` work under the hood?
- How would you design a platform starter that enforces tracing and metrics across all services?
- What breaks if you use `@Configuration` instead of `@AutoConfiguration`?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.