Spring АйО

🦉 Один поток закончился. Следующий уже в продакшене!

Во-первых, всех с началом учебного года.

А во-вторых, давайте учиться. Весной мы провели первый поток Spring АйО Академии «Продвинутый Hibernate». И, судя по обратной связи, попали точно в цель.

Мы собрали от участников отзывы. Ознакомиться с ними можно на главной странице Академии.

Поэтому продолжаем.

Открываем набор на новую осеннюю программу «Java в продакшене».

Эта программа для Java- и Spring-разработчиков, которым уже мало просто написать работающий сервис. Пора разобраться, как он будет вести себя под реальной нагрузкой, во время сбоев и на релизах.

За 6 лекций разберём:

— Circuit Breaking, Bulkhead и Load Shedding;
— таймауты, ретраи, backoff + jitter и идемпотентность;
— метрики, трассировку и логи с OpenTelemetry;
— Blue/Green, Canary и релизы без простоя;
— Vault, ротацию и защиту секретов;
— эволюцию API без поломки клиентов.

В программе 12 часов живых занятий с Михаилом Поливаха, домашние задания с разбором, общение в закрытой группе и доступ к материалам на 90 дней.

Если вы движетесь к уровню Senior/Staff, отвечаете за SLA и релизы или дежурите on-call, то у нас мэтч.

🔗 Посмотреть программу и записаться

🙃 Ну потому что works on my machine для серьёзных систем уже недостаточно

🥇 Лучшие практики управления конфигурацией в Spring Boot

Конфигурация Spring Boot приложений гораздо более сложная, чем может показаться на первый взгляд.

Spring Framework позволяет потреблять конфигурацию из разных источников:

- System Properties
- Переменные окружения процесса ОС
- Java Properties / YAML файлы и т.д.

Как следствие сложно понять итоговое значение, а ошибка всплывает уже в работе. Кроме того, помимо потребления конфигурации, Spring Boot в частности позволяет получать свойства конфигурации разными способами:

- @Value
- @ConfigurationProperties
- Environment / PropertySource-ы и т.д.

Всё это способно создать небольшую кашу в голове. В новом переводе мы вместе постараемся внести небольшую ясность в этот процесс.

🔗 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1076862/

Anthropic опубликовали AI-Native SDLC плейбук

Его основная мысль: агенты уже способны генерировать код намного быстрее человека, но окружающие процессы почти не изменились. Планирование, согласования, тестирование, проверка безопасности и выпуск по-прежнему работают с человеческой скоростью.

Узкое место просто переместилось из написания кода в соседние этапы.

Anthropic называет предлагаемую модель AI-native SDLC. Привычный линейный процесс превращается в замкнутый цикл, внутри которого каждый этап создает версионируемый артефакт для следующего:

intent.md -> spec.md -> plan.md -> код и тесты -> PR с результатами проверок -> отчет об инциденте или новый intent.md

Все это хранится в Git. История коммитов одновременно становится журналом изменений: кто сформулировал задачу, что предложил агент, какие решения принял человек и что в итоге попало в продакшен.

Как выглядит сам процесс?

На этапе планирования автор идеи обсуждает проблему с Claude. Результат фиксируется в intent.md: что требуется изменить, зачем, какие системы затрагиваются и какие ограничения нужно учитывать. Владелец продукта проверяет документ и принимает решение о продолжении работы.

Дальше агент превращает намерение в spec.md с требованиями и проектным решением. Политики безопасности, архитектурные правила и требования к интерфейсу подключаются через Skills. Спорные места агент должен явно отметить, а человек - разрешить до начала реализации.

Разработка начинается с plan.md. В нем перечисляются изменяемые файлы, порядок работы, риски и проверки результата. После утверждения плана агент пишет код. Контекст проекта хранится в CLAUDE.md, повторяемые правила оформляются как Skills, а обязательные ограничения обеспечиваются через hooks.

Для тестирования предлагается два уровня. Первый - обычные сборка, линтеры и автоматические тесты, которые агент обязан запустить перед завершением задачи. Второй - evals для проверки самого агента. Если команда меняет модель, системные инструкции, Skills или hooks, набор реальных задач должен показать, что качество работы не ухудшилось.

Во время развертывания агент проверяет PR, исправляет замечания и готовит релиз. Человек оценивает соответствие исходному замыслу и уровень риска. Критические действия, включая выпуск в продакшен, защищаются программными ограничениями и явными согласованиями.

Эксплуатация замыкает цикл. Детерминированный мониторинг обнаруживает выход метрик за допустимые границы, после чего агент подключается к диагностике. Небольшая проблема может закончиться PR или откатом. Более крупная превращается в новый intent.md и снова проходит весь процесс.

Роль инженера в такой модели заметно меняется. Больше внимания уходит на формулирование намерения, проектирование ограничений, проверку артефактов и оценку риска. Стабильность процесса обеспечивают тесты, CI, изоляция, права доступа и автоматические шлюзы.

Плейбук сильно привязан к Claude Code и продуктам Anthropic, однако сама схема применима шире. Главная идея заключается в перестройке всего процесса разработки вокруг работы агентов, а не в добавлении генерации кода в одну из существующих стадий.

Плейбук в блоге Anthropic:
https://claude.com/blog/the-ai-native-sdlc-playbook

Какой подход при разработке с ИИ-агентами используете вы в рабочих проектах? Пишите в комментариях 😎

🖥 Ваш JSONB тормозит не из-за базы. Возможно, виноват Hibernate

Когда Hibernate начинает проседать по производительности, первым делом обычно ищут лишние SQL-запросы.

Тем не менее, с JSON или JSONB проблема может скрываться совсем в другом месте.

Hibernate способен незаметно выполнять дорогую работу с JSON-объектами, даже когда вы этого не ожидаете. На небольших объёмах это почти не видно, а под нагрузкой превращается в серьёзный bottleneck.

Хорошая новость состоит в том, что часто проблема решается довольно просто, и хватает всего пары аннотаций, чтобы сократить время обработки почти вдвое.

🔗 Что именно происходило и как это исправить:
https://habr.com/ru/companies/spring_aio/articles/1075156/

👩‍💻 В Java хотят дать возможность запретить читать поле до того, как ему присвоили значение

Дело в том, что, когда создаётся объект, его поля сначала получают значения по умолчанию (null для ссылок, 0 для чисел, false для boolean) и только затем выполняется код инициализации.

По итогу на уровне JVM существует короткий промежуток времени, когда поле уже можно прочитать, хотя ему ещё не присвоили настоящее значение. Давайте рассмотрим вот такой пример:

class Parent {
    Parent() {
        // Вызов попадёт в переопределённый метод Child (dynamic dispatch),
        // хотя конструктор Child ещё не закончил выполняться!
        printValue();
    }

    void printValue() {}
}

class Child extends Parent {
    private final int value;

    Child() {
        // Неявный super() уже был вызван, и только после него полю "value" присвоится 42.
        this.value = 42;
    }

    @Override
    void printValue() {
        // Пока выполняется Parent(), здесь всё ещё значение по умолчанию - печатается 0, а не 42
        System.out.println(value);
    }
}

И вот OpenJDK хочет сделать шаг на пути исправления этой проблемы. В рамках JEP 539 завозят новый механизм "строгих полей" (strict fields). Их поведение будет немного отличаться в зависимости от того, static поле или нет, но цель одна - не допустить ситуации выше.

Например, если пометить value поле выше как strict (сейчас вы это никак не сделаете), то при загрузке класса будет VerifyError, т.к. строгие поля объектов необходимо присвоить до вызова super().

То есть Parent() уже не сможет вызвать printValue() и увидеть промежуточный 0: JVM отклонит некорректный байткод ещё при его проверке.

Зачем вообще нечто подобное делать? В основном ради Project Valhalla и концепции "Integrity By Default", о которой мы уже писали.

Java движется к value classes, а для них состояние объекта должно иметь гораздо более строгие гарантии. С точки зрения пользователя, Value классы нужны в основном для скаляризации (Вспоминаем девиз: "codes like a 'class', works like an 'int'"). А для того, чтобы JIT мог эффективно скаляризировать классы, он должен быть абсолютно уверен, что наблюдаемое им состояние объекта единственно верное, и остальные наблюдают его ровно таким же.

Проблема в том, что даже для final полей в Java это не так. С одной стороны из-за проблемы выше, а с другой из-за того, что final на самом деле не совсем final.

Соответственно, примерно через полгода мы уже, скорее всего, увидим эту фичу в preview. Подробнее можно почитать в самом JEP.

⚠️ Важно! Механизм строгих полей это opt-in механизм, который пока, по умолчанию, будет касаться только value классов. Существующий код механизм "строгих полей" пока не касается!.

🔗 JEP 539: https://openjdk.org/jeps/539

Вам доклады по Go или Java? VK приглашает на митап с двойной начинкой
26 августа VK собирает Go- и Java-инженеров, чтобы прокачать знания.

В программе два трека — Go и Java, по три доклада в каждом.

Трек Go:
• «Компиляция Go в динамическую либу, или как мы ускорили выкатку фичи в два раза, но нам не понравилось», Михаил Кичигин, бэкенд-разработчик, Avito Tech
• «Go-платформа VK: как мы построили единую основу для создания Go-сервисов», Александр Апанасенко, руководитель команды SDK Backend, VK
• «Почтальон от Kubernetes до Palo Alto. Как осуществляется доставка информации об адресах», Дарья Кулькина, бэкенд-разработчик, Точка Банк

Трек Java:
• «Перформанс-трюки в поисковой платформе Ozon», Пётр Портнов, ведущий разработчик среднего поиска, Ozon
• «Архитектура современного движка платёжной системы и переход к новой архитектуре», Игорь Крикунов, технический лидер разработки DBC, Альфа-Банк
• «Переход от федерации S3-кластеров в пользу коммунального и мультитенантного кластера», Кирилл Боблак, ведущий разработчик One-cloud, VK

А ещё будет мастер-класс по прокачке навыка, который сделает вас звездой любого вечера, и афтепати, чтобы обсудить доклады в неформальной обстановке.

Встречаемся в 17:00, начало в 18:00. Участие бесплатное, регистрация обязательна.

🍃 ИИ придумал уязвимости, IDE всё ещё нужна, Spring Boot vs Quarkus | Spring АйО Подкаст №71

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE
🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ
🤩 СЛУШАТЬ НА SPOTIFY
🤩 СЛУШАТЬ НА APPLE PODCASTS

💬 Аудио версию подкаста можно найти в комментариях

Вам доклады по Go или Java? VK приглашает на митап с двойной начинкой
26 августа VK собирает Go- и Java-инженеров, чтобы прокачать знания.

В программе два трека — Go и Java, по три доклада в каждом.

Трек Go:
• «Компиляция Go в динамическую либу, или как мы ускорили выкатку фичи в два раза, но нам не понравилось», Михаил Кичигин, бэкенд-разработчик, Avito Tech
• «Go-платформа VK: как мы построили единую основу для создания Go-сервисов», Александр Апанасенко, руководитель команды SDK Backend, VK
• «Почтальон от Kubernetes до Palo Alto. Как осуществляется доставка информации об адресах», Дарья Кулькина, бэкенд-разработчик, Точка Банк

Трек Java:
• «Перформанс-трюки в поисковой платформе Ozon», Пётр Портнов, ведущий разработчик среднего поиска, Ozon
• «Архитектура современного движка платёжной системы и переход к новой архитектуре», Игорь Крикунов, технический лидер разработки DBC, Альфа-Банк
• «Переход от федерации S3-кластеров в пользу коммунального и мультитенантного кластера», Кирилл Боблак, ведущий разработчик One-cloud, VK

А ещё будет мастер-класс по прокачке навыка, который сделает вас звездой любого вечера, и афтепати, чтобы обсудить доклады в неформальной обстановке.

Встречаемся в 17:00, начало в 18:00. Участие бесплатное, регистрация обязательна.

👩‍💻 One Branch To Rule Them All

Модель ветвления git в современных проектах - это отдельная головная боль. Кажется, что что бы ты ни делал - ты всё равно проиграешь. В итоге каждый проект решает данную проблему по-своему.

Существуют разные модели ветвления:

- GitFlow
- GitHub-flow
- TBD и так далее

И разные модели бранчинга страдают от разных проблем. Кто-то сталкивается с merge hell, а кто-то - с огромными накладными расходами на процессы CI и тестирования.

В данной статье парни из Axelix описали, какую модель ветвления они адаптировали под свой монорепозиторий.

⚠️ Спойлер: Стоит признать, что модель Axelix подойдет далеко не всем, т.к. у них Monorepo с Lockstep версионированием.

К тому же, их модель, как и любая другая, имеет ряд проблем, которые также честно описаны в статье.

Будет интересно всем, кто когда-либо интересовался разными стратегиями бранчинга на проектах. Приятного чтения!

📎 Статья: https://habr.com/ru/companies/spring_aio/articles/1072386/

🤖 ИИ настолько ускорил поиск уязвимостей, что команде Spring пришлось менять процессы безопасности

За последний месяц количество сообщений о потенциальных уязвимостях в проектах Spring выросло более чем на 1700% (!).

Причина неожиданная: массовое использование AI-инструментов для поиска багов.

Команда Spring признаёт, что объём обращений оказался беспрецедентным. Чтобы справиться с нагрузкой, пришлось изменить внутренние процессы обработки сообщений и выпустить крупнейшую за всю историю проекта волну исправлений безопасности.

В целом это отличная новость. Ведь чем больше найдено уязвимостей, тем безопаснее станет экосистема.

Но, как говорится в том самом анекдоте про Петьку и Василиваныча, есть нюанс.

ИИ кардинально снизил стоимость поиска потенциальных проблем. Сегодня исследователь может за несколько часов проверить объём кода, на который раньше уходили дни или недели. Вместе с действительно важными находками резко вырос поток ложных срабатываний, дубликатов и сообщений с недостаточной проработкой.

Получается интересная ситуация. Раньше главным ограничением было найти уязвимость.
Теперь всё чаще главным ограничением становится проверить, действительно ли она существует.

И это касается не только Spring. Аналогичные изменения уже происходят и в других крупных open source-проектах.

Погнали по примерам.

1. cURL закрыл программу bug bounty из-за потока AI-отчётов

Разработчик cURL Даниэль Стенберг объявил о закрытии HackerOne-программы после того, как количество ложных сообщений резко выросло.

По данным OpenSSF:
– к июлю 2025 года около 95% сообщений оказались недействительными;
– объём заявок вырос примерно в 8 раз по сравнению с исторической нормой;
– основная проблема — AI-сгенерированные отчёты, проверка каждого из которых требует времени человека.

2. OpenSSF выпустила отдельное руководство для мейнтейнеров

Open Source Security Foundation (OpenSSF) и CNCF даже подготовили специальный документ "Securing Open Source in the Age of AI".

Они прямо пишут, что LLM могут находить уязвимости и генерировать отчёты с беспрецедентной скоростью, но это создаёт новую операционную проблему: сопровождающие проектов оказываются завалены отчётами, каждый из которых приходится проверять вручную.

3. AI-DDoS

В июле 2026 года вышла работа с говорящим названием "AI Slop is DDoSing Open Source"

Авторы проанализировали 294 популярных GitHub-проекта и пришли к выводу, что после массового распространения генеративного ИИ:
– число pull request'ов выросло;
– процент принимаемых изменений снизился;
– сильнее всего пострадали проекты, живущие за счёт добровольцев.

Они даже ввели термин AI-DDoS. Это ситуация, когда проект оказывается перегружен не запросами к серверу, а правдоподобными, но низкокачественными AI-сгенерированными вкладами.

Похоже, в ближайшие годы команды безопасности будут автоматизировать не только поиск уязвимостей, но и проверку самих отчётов об уязвимостях.

🔗 Источник: https://blogs.vmware.com/tanzu/broadcoms-investment-in-spring-to-combat-ai-fueled-security-challenges-in-the-enterprise/

🔥 Эксперты Spring АйО покажут крутую IDE

27 августа в 11:00 эксперты Spring АйО Илья Сазонов и Фёдор Сазонов обещают показать актуальное состояние OpenIDE Pro:

– Как OpenIDE Pro работает с Java/Spring и другими популярными технологическими стеками;
– Встроенный DB-клиент: подключение к базам данных, SQL-консоль, просмотр схем и работа с данными прямо из IDE;
– Актуальное состояние AI-агентов в IDE.

Особенно полезно для разработчиков, тимлидов, архитекторов и платформенных команд.

🌐 Онлайн, 27 августа в 11:00, бесплатно.
🔗 Зарегистрироваться на вебинар

👩‍💻 Oracle хочет, чтобы ИИ писал не только код, но и плагины

В GraalVM 25.2 Oracle представила Graal Script Agent. Это очередная новая либа (пока в статусе Early Access), которая позволяет описывать логику на естественном языке и превращать её в локально выполняемые скрипты и плагины.

Интересно получается в целом. Вместо того чтобы каждый раз писать Java-код для простой автоматизации, можно дать ИИ задачу типа:

«Напиши скрипт, который анализирует входящий JSON, фильтрует записи и отправляет результат в REST API».

Дальше агент генерирует код, который выполняется локально через GraalVM.

Понятно, что это не замена полноценной разработке. Но для интеграций, автоматизации и прототипирования такой подход имеет право на жизнь.

Кроме AI Script Agent, в GraalVM 25.2 появились и другие изменения:

• G1 GC теперь поддерживается в Native Image на всех основных платформах, включая Windows.
• Vector API включён по умолчанию, что должно упростить использование SIMD-оптимизаций без дополнительной настройки.

Пока рано говорить востребованности сей мероприятия. Поживем-увидим, как говорится.

🔗 Подробнее: https://www.infoq.com/news/2026/08/java-news-roundup-jul27-2026/

👩‍💻 AI Agent-ы в Open Source разработке на Java

Друзья, всем привет!

Недавно вышла запись доклада, где наш эксперт, Михаил Поливаха, выступал на конференции AgenticConf с докладом "Axelix: Scaling Open Source with AI".

Если вам интересно, как осознанно, на практике и без лишнего хайпа внедряются AI Agent-ы в процесс разработки (и где они не внедряются) - этот доклад для вас.

Важно ещё и то, что исходный код ядра Axelix является Open Sourcе и лежит на GitHub, поэтому все детали можно увидеть своими глазами.

Приятного просмотра!

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО

☕️ Дождались. 30 лет без встроенной поддержки JSON

Согласитесь, сейчас ну нет Java-проекта, в котором нет Jackson, Gson или JSON-B.

Даже если нужно просто прочитать небольшой JSON-файл или отправить простой HTTP-запрос, почти всегда приходится подключать стороннюю библиотеку.

И это реально странно. Не находите?

У нас в стандартной библиотеке Java есть:

– HTTP-клиент
– Работа с XML
– ZIP, Base64, криптография, регулярные выражения…

НО САМОГО РАСПРОСТРАНЕННОГО ФОРМАТА ОБМЕНА ДАННЫМИ - НЕТ.

Наконец-то, в OpenJDK решили наконец закрыть этот момент.

Итак, в JDK 28 предложен JEP 540: Simple JSON API. Это небольшой стандартный API для чтения, записи и построения JSON без сторонних зависимостей. Спасибо.

Но суть не в том, чтобы заменить Jackson. Скорее наоборот.

Jackson останется лучшим выбором для Spring-приложений, сложной сериализации, аннотаций, стриминга и огромной экосистемы.

Новый API решает другую задачу.

Представим, что мы пишем:

- небольшую CLI-утилиту;
- агент;
- библиотеку;
- Gradle-плагин;
- простой микросервис.

Вместо того чтобы добавлять ещё одну зависимость только ради пары строк JSON, можно будет воспользоваться тем, что уже есть в JDK.

Теперь интересно другое.
Если JEP примут, что вы выберете в новом проекте?

👍 Стандартный JSON API из JDK.
🔥 Jackson, потому что он всё равно намного мощнее.

🔗 JEP 540: https://openjdk.org/jeps/540

🔔 У Spring АйО снова пары: митап для Java-разработчиков

20 августа приглашаем Java-разработчиков и тимлидов вернуться в универ. Вместе с экспертами Spring АйО и PVS-Studio обсудим, как меняются привычные инструменты и подходы к разработке.

В программе:

☑️ Spring и ИИ
Посмотрим, как ИИ-агенты влияют на разработку Spring, создание фич и сам фреймворк.

☑️ Внутреннее устройство компилятора
Разберемся, что происходит с исходным кодом до появления байткода: от лексического анализа и парсинга до построения AST. А затем посмотрим, как это используется в статическом анализе и поиске проблем безопасности.

☑️ ИИ и реальные системы
Поговорим о том, почему сгенерированный Spring Boot-сервис еще не готов к продакшену и какие задачи остаются за инженером.


📅 Когда: 20 августа, 19:00
📍 Где: кампус Центрального университета, Москва, ул. Гашека, 7
🔗 Регистрация, программа и информация о спикерах

Попасть в кампус можно до 19:30. На входе понадобится паспорт или водительские права.

👩‍💻 Яблочники (только те, что на Intel), плохие новости

В OpenJDK появился JEP 541, предлагающий прекратить поддержку macOS x64 начиная с JDK 28.

Когда-то Intel Mac был практически эталонной машиной для Java-разработчика.
Но мир меняется.

После перехода Apple на собственные процессоры прошло уже несколько лет, и сегодня подавляющее большинство новых Mac выпускается на Apple Silicon.

В целом то понятно, что поддержка двух архитектур одновременно это не только дополнительные сборки.

Это ещё и:

• отдельное тестирование;
• поддержка CI;
• исправление платформенных багов;
• ресурсы разработчиков OpenJDK.

В какой-то момент цена такой поддержки становится выше, чем её польза. Для большинства разработчиков эта новость никак не повлияет ни на что.

Но если вы, всё ещё работаете на Intel Mac: платформа постепенно переходит в категорию legacy.

А помните, что несколько лет назад многие сомневались, сможет ли ARM стать основной архитектурой для профессиональной разработки. Сегодня вопрос звучит уже иначе. Не «стоит ли переходить на Apple Silicon?», а «сколько ещё будут поддерживать Intel?».

🔗 JEP 541: https://openjdk.org/jeps/541

🚨 У RestTemplate истекает срок годности

Команда Spring официально перевела RestTemplate в статус @Deprecated в Spring Framework 7.1.

😄 Пора переходить на RestClient? Или еще подождем?

Хронология:

• Spring 6.1 — появился RestClient;
• Spring 7.1 — RestTemplate официально помечен как @Deprecated;
• Spring 8.0 — RestTemplate планируют удалить.

Для многих это конец целой эпохи.

RestTemplate появился ещё в 2009 году вместе со Spring 3 и больше 15 лет был стандартным способом отправлять HTTP-запросы. Но его API перестал масштабироваться.

Каждая новая фича требовала десятков перегруженных методов (getForObject(), exchange(), postForEntity()...), из-за чего развивать клиент становилось всё сложнее.

Видимо, именно поэтому Spring сделал ставку на RestClient — современный модный молодежный fluent API, который уже используется как основной синхронный HTTP-клиент.

❗️Это не значит, что завтра бежим переписывать все проекты.

Но если вы вдруг на следующей неделе планировали писать новый сервис, использовать RestTemplate уже не надо. Если же поддерживаете существующий код, стоило бы запланировать постепенную миграцию, пока она не превратилась в обязательную.

Много кто у нас на RestClient сидит?

👍 Да, перешли.
🤔 Пока остаёмся на RestTemplate.
🔥 Для синхронных вызовов давно используем WebClient.

🔗 Release Notes Spring Framework 7.1: https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-7.1-Release-Notes

🔥 Aston & Spring АйО

Друзья, всем привет!

Наконец-то, вышла запись нашего митапа с Aston!

На митапе выступали эксперты сообщества:

• Михаил Поливаха. Тема: устройство Spring AOP и проксирования под капотом в Spring Framework (с примерами из Axelix OSS).

• Евгений Сулейманов. Тема: правильная работа с Dead Letter Topics в современных production системах.

Приятного просмотра!

😉 СМОТРЕТЬ НА YOUTUBE

⚡️ Spring играет в оптимизацию

В Spring Framework 7.1 изменили поведение, которое большинство разработчиков даже не замечало.

Раньше при запуске приложения Spring автоматически проверял, доступен ли JAXB, и, если находил его, регистрировал XML-конвертер.

Даже если ваше приложение вообще НИКОГДА не работало с XML.

Теперь это поведение изменили.

Для серверных приложений Spring больше не подключает JAXB автоматически. Если XML действительно нужен, то его придётся включить явно. Вот.

Много профита дает? Надо тестить. Spring цифр не дает.

We noticed that the JAXB message converter can consume a lot of CPU resources at runtime, even if XML isn't being used by the application.

В любом случае автоматическое определение компонентов не бесплатно само по себе.

Это:
- дополнительные проверки при старте;
- лишняя работа ClassLoader;
- расход CPU;
- усложнение процесса инициализации.

По отдельности это мелочи. Но именно из таких мелочей складывается время запуска современных приложений. Раньше фреймворк старался угадать, что может понадобиться разработчику.

Теперь всё чаще действует другой принцип:

Не делай ничего, пока тебя об этом явно не попросили.

И, кажется, это правильно.

🔗 Источник: Spring Framework 7.1 Release Notes
https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-7.1-Release-Notes