Короткий ответ
Spring Boot Starters — предварительно сконфигурированные наборы зависимостей: вместо ручного добавления и согласования версий десятков JAR достаточно подключить один стартер, и нужные библиотеки подтянутся автоматически. Это устраняет конфликты версий и сокращает конфигурацию сборки.
Как это работает подробнее
Стартер — это один артефакт, который включает все библиотеки для конкретной функциональности или типа приложения. Присутствие стартеров в classpath во многом определяет, какие авто-конфигурации применит Spring Boot. Совместимость версий транзитивных зависимостей обеспечивают родительский POM spring-boot-starter-parent и BOM spring-boot-dependencies.
- spring-boot-starter-web — веб-приложения и REST API: Spring MVC и встроенный Tomcat.
- spring-boot-starter-data-jpa — работа с базой данных через JPA и Hibernate.
- spring-boot-starter-security — аутентификация и авторизация.
- spring-boot-starter-test — тестирование: JUnit, Mockito и Spring Test.
- spring-boot-starter-actuator — мониторинг и health-проверки приложения; spring-boot-starter-thymeleaf — шаблоны Thymeleaf.
Пример кода
pom.xml (фрагмент)
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>Что использовать на практике
- Начинайте проект с нужного стартера: для REST API —
spring-boot-starter-web, для работы с БД —spring-boot-starter-data-jpa. - Версии указывать не нужно: их согласуют
spring-boot-starter-parentи BOMspring-boot-dependencies.
Подводные камни
- Не добавляйте библиотеки по одной, если есть подходящий стартер, — это провоцирует конфликты версий.
- Стартеры лишь подтягивают библиотеки в classpath: именно по ним затем срабатывает авто-конфигурация Spring Boot.
Как отвечать на собеседовании
- Дайте определение стартера как готового набора зависимостей → поясните выгоду: один артефакт вместо десятка JAR, версии согласуются автоматически → приведите 2–3 примера (web, data-jpa, security, test) → упомяните связь стартеров с авто-конфигурацией.