Master Spring Boot Starters: In‑Depth Analysis, Interview Self‑Test, and Real‑World Examples

Interview Self‑Test Checklist

The article provides a table of 15 interview questions covering Spring Boot Starters and their underlying mechanisms, each linked to the corresponding chapter in the original guide.

1. Difference Between Starter and AutoConfiguration

Starter ( xxx-spring-boot-starter) is a pure pom module that only declares transitive dependencies; its responsibility is to bring the required JARs into the project.

AutoConfiguration ( xxx-spring-boot-autoconfigure) is a JAR that contains configuration classes, @ConfigurationProperties classes, and registration files (e.g., .imports). Its responsibility is to create beans under specific conditions.

Example with the official Web starter:

spring-boot-starter-web (pure pom)
    └── dependency → spring-boot-starter
    └── dependency → spring-boot-autoconfigure (jar)
            └── ServletWebServerFactoryAutoConfiguration.java
            └── DispatcherServletAutoConfiguration.java

Reasons for separation:

Decoupling : dependency management and configuration logic evolve independently.

Flexibility : users can import only the auto‑configuration module if they need finer control.

Official convention : Spring Boot uses the spring-boot-starter-{name} + spring-boot-autoconfigure split; third‑party starters follow {name}-spring-boot-starter + {name}-spring-boot-autoconfigure.

2. Role of Maven Transitive Dependencies in a Starter

Transitive dependencies enable the “one‑click” inclusion of all required libraries. Adding spring-boot-starter-web pulls in a whole dependency tree (Spring Boot core, embedded Tomcat, Spring MVC, Jackson, validation, etc.).

Benefits:

Users do not need to manage version compatibility.

Reduces configuration effort to a single dependency declaration.

Encapsulates best‑practice dependency sets maintained by the Spring Boot team.

Command to view the full tree: mvn dependency:tree.

3. Registration File for Auto‑Configuration in Spring Boot 3.x

Spring Boot 3.x registers auto‑configuration classes via the file:

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

Each line contains a fully‑qualified class name. Compared with Spring Boot 2.x, which used META-INF/spring.factories with a key‑value format, the new format is simpler and still compatible (the old file is deprecated).

4. @ConfigurationProperties Binding Process

The binding is performed by Binder in four steps:

Property source extraction : application.properties or application.yml are turned into ConfigurationPropertySource objects.

Property name normalization : Various naming styles (kebab‑case, camelCase, underscore, etc.) are normalized to a canonical form.

Binder.bind() : Reflectively populates the target bean’s fields, using ConversionService for type conversion.

BindHandler chain : Executes handlers such as NoOpBindHandler, Validator (for @Validated), Converter, and IgnoreTopLevelConverterBindHandler.

Example code:

Binder binder = Binder.get(environment);
GreetingProperties props = binder.bind("greeting", Bindable.of(GreetingProperties.class)).orElseThrow();

Note: the target class must follow JavaBean conventions (getter/setter) or be a record.

5. Changes to Relaxed Binding in Spring Boot 3.x

Spring Boot 3.x tightens the relaxed‑binding rules. While 2.x accepted many formats (e.g., greeting.prefix, greetingPrefix, GREETING_PREFIX, Greeting.Prefix), 3.x only supports kebab‑case and camelCase. Upper‑case with underscores is no longer valid because NormalizedPropertyName enforces stricter validation.

Recommended format:

# recommended
greeting.prefix=Hello
greeting.smart=true

During migration, all uppercase‑underscore properties must be renamed.

6. @EnableConfigurationProperties Annotation

The annotation registers classes annotated with @ConfigurationProperties as Spring beans. Internally, ConfigurationPropertiesBeanRegistrar (an ImportBeanDefinitionRegistrar) scans the annotation, creates a BeanDefinition for each class, and the ConfigurationPropertiesBindingPostProcessor (a BeanPostProcessor) binds and validates the properties before bean initialization.

If the class is also annotated with @Component, component scanning registers it automatically, making @EnableConfigurationProperties optional in that case.

7. Execution Time of ConfigurationPropertiesBindingPostProcessor

The processor implements BeanPostProcessor and runs during the bean initialization phase, specifically in the postProcessBeforeInitialization callback (i.e., before @PostConstruct methods are invoked).

Bean lifecycle excerpt:

Instantiation → Populate (Autowired) → postProcessBeforeInitialization (binding) → InitializingBean → @PostConstruct → postProcessAfterInitialization

8. spring-boot-configuration-processor Dependency Type

This artifact is a compile‑time tool ( compile‑time dependency ) that generates additional-spring-configuration-metadata.json for IDE assistance. It is marked optional=true in Maven, proving it is not required at runtime.

9. Why @ConditionalOnMissingBean Is Essential for Starters

The annotation enables “convention‑over‑configuration”: a default bean is created only when the user has not defined their own bean of the same type, allowing easy replacement of starter defaults.

Typical usage:

@Bean
@ConditionalOnMissingBean(GreetingService.class)
public GreetingService greetingService() {
    return new DefaultGreetingService();
}

If the user provides a custom GreetingService, the starter’s bean is skipped.

10. Naming Conventions for Official vs. Third‑Party Starters

Official starters follow spring-boot-starter-{name} (e.g., spring-boot-starter-web).

Third‑party or internal starters use {name}-spring-boot-starter (e.g., mybatis-spring-boot-starter, msg-spring-boot-starter).

11. Ways to Exclude an Auto‑Configuration Class

Annotation exclusion :

@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})

.

Configuration‑file exclusion : set

spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

in application.properties or the equivalent YAML.

Conditional annotation : use @ConditionalOnClass, @ConditionalOnProperty, etc., inside the starter (design‑time, not user‑driven).

Debugging can be aided by the --debug flag, which prints auto‑configuration evaluation results.

12. Problems Caused by Too Many Starters and How to Diagnose

Slow startup : each auto‑configuration class (often >200 in Spring Boot 3.x) must be evaluated.

Configuration conflicts : different starters may pull incompatible library versions.

Unwanted transitive dependencies : increase artifact size and may introduce unnecessary functionality.

Investigation steps:

Run mvn dependency:tree to view the full dependency graph.

Run mvn dependency:tree -Dverbose to see conflict resolution.

Start the application with --debug to get an auto‑configuration report.

Exclude unnecessary auto‑configurations via @SpringBootApplication(exclude = …) or spring.autoconfigure.exclude.

Periodically review and remove unused starters.

13. “Dependency Description vs Auto‑Configuration Separation” Design

The pattern splits a starter into two modules:

my-spring-boot-starter (pom, no code)
    └── my-spring-boot-autoconfigure (jar, contains MyAutoConfiguration.java, MyProperties.java, and the imports file)

Advantages:

Clear responsibilities – the pom declares dependencies, the jar provides bean creation logic.

Fine‑grained control – users can depend only on the auto‑configuration module if they want.

Independent versioning – the two modules can evolve separately.

Aligns with the official Spring Boot convention.

14. Meaning of matchIfMissing = true in @ConditionalOnProperty

If the specified property is absent, the condition is considered matched (treated as true), so the bean will be created.

Example matrix:

Property greeting.smart=false → condition matches → bean created.

Property greeting.smart=true → condition does not match → bean not created.

No property defined → matchIfMissing=true makes the condition match → bean created.

Omitting matchIfMissing would prevent bean creation when the property is missing.

15. Difference Between ApplicationContextRunner and @SpringBootTest

@SpringBootTest

: launches a full Spring Boot application context, loads all auto‑configurations and component scans; suitable for integration tests; slower and resource‑heavy. ApplicationContextRunner: creates a lightweight context that loads only the specified configuration classes; allows fine‑grained property and user‑configuration setup; fast and ideal for unit testing individual auto‑configuration conditions.

Typical usage:

@SpringBootTest
class StarterIntegrationTest {
    @Autowired GreetingService greetingService;
    @Test void greetingServiceAutoConfigured() {
        assertNotNull(greetingService);
    }
}

private final ApplicationContextRunner runner = new ApplicationContextRunner()
        .withUserConfiguration(GreetingAutoConfiguration.class);

@Test
void smartGreetingWhenSmartEnabled() {
    runner.withPropertyValues("greeting.smart=true")
          .run(context -> {
              assertTrue(context.containsBean("smartGreetingService"));
              assertFalse(context.containsBean("defaultGreetingService"));
          });
}

For starter development, prefer ApplicationContextRunner for fast, isolated tests; use @SpringBootTest only when full‑stack behavior must be verified.

References

Starter全解析与案例应用（原文）

Spring Boot 官方文档 – Creating Your Own Starter

Spring Boot 源码 – spring-boot-autoconfigure