В чем разница между стартером и обычной зависимостью в Spring

Что проверяют

Понимаете ли вы, что стартер это не библиотека с кодом, а набор зависимостей плюс автоконфигурация. Ответ показывает, разбираетесь ли вы в сборке проекта или подключаете строки из статей.

Как отвечать

Обычная зависимость это библиотека с классами: подключили и пользуетесь её API, настраивая всё сами.

Стартер Spring Boot это пакет-агрегатор. Своего кода в нём почти нет, зато он тянет согласованный набор библиотек нужных версий и, главное, приносит автоконфигурацию, которая поднимает готовые бины по тому, что оказалось в classpath.

Пример: spring-boot-starter-web притягивает Spring MVC, встроенный Tomcat, Jackson и валидацию, а автоконфигурация сама поднимает DispatcherServlet, конвертеры JSON и обработку ошибок. Вручную это десяток зависимостей и полсотни строк конфигурации.

Что стоит добавить:

• версии приходят от родительского спецификатора зависимостей (spring-boot-dependencies), поэтому у библиотек нет конфликтов между собой. Указывать версию у стартера не нужно и вредно;
• своя автоконфигурация пишется так же: класс с условными аннотациями плюс регистрация в META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports. Внутренние стартеры компании это обычная практика;
• посмотреть, что сработало, можно запуском с --debug: отчёт покажет применённые и отклонённые конфигурации с причинами;
• отключить лишнее можно через exclude в аннотации приложения или свойство spring.autoconfigure.exclude.

Где спотыкаются

Считают, что стартер это просто «библиотека для Spring», и не могут объяснить, откуда берутся бины, которых никто не объявлял.

Прописывают версии стартеров руками и ломают согласованность набора.

Подключают несколько стартеров с пересекающимися ролями (например, два веб-стека сразу) и потом ищут, почему поднялся не тот сервер.