⏳ Лучше поздно, чем никогда. Команда Spring про Spring Framework 7 и Spring Boot 4

Итак, в конце 2025 вышел Spring Boot 4 и Spring Framework 7. InfoQ взяли интервью у core команды Spring с целью узнать, куда движется самая популярная в Java экосистема.

Spring Boot 4 модуляризировал автоконфигурацию. Теперь при запуске проверяется меньше классов в classpath, а uber-jar будет более компактным: будут подключаться только нужные модули. Параллельно Spring Boot 4 переходит на Jackson 3, но добавлен модуль совместимости с Jackson 2, потому что экосистема ещё догоняет.

Spring Framework 7 тащит core resilience в ядро: RetryTemplate, @Retryable и @ConcurrencyLimit доступны без отдельной зависимости. @Retryable работает и с реактивными типами (через Retry из Project Reactor); для обычных вызовов используется RetryTemplate с политикой retry/backoff. @ConcurrencyLimit помогает ограничивать доступ к ресурсу, что особенно полезно с Virtual Threads.

Особое внимание команда Spring уделила AI Agent-ам и потенциальной поддержке тулинга для AI Agent-ов в рамках проекта Spring Tools.

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

👋 Гудбай Spring Boot 3.5

⛔️В июне у Spring Boot 3.5 заканчивается open-source поддержка.

Что делать с безопасностью, как планировать обновление и нужен ли вообще сценарий с расширенной поддержкой.

Наши друзья из Axiom JDK, как раз проводят опрос на эту тему. Нам всем очень важно понять:

☑️кто уже готовит обновление;
☑️насколько важны security-фиксы;
☑️есть ли запрос на расширенную поддержку Spring;
☑️и кого изменения почти не затрагивают.

⛔️Ведь именно от вашего мнения будет зависеть наша будущая работа со Spring.

Опрос займет не больше 10 минут.

После исследования соберем все в крутую статейку. А среди участников опроса будет разыгран мерч 😎

Ну а пока:

👉 Пройти опрос: https://anketolog.ru/re/155748549/HuIH8s7E

🧠 Сила не только в модели: зачем Skills AI-агентам

По данным SkillsBench — первого бенчмарка, который системно измеряет, как Agent Skills влияют на качество работы агентов, — Skills в среднем улучшают результат на 16.2 процентного пункта на 84 задачах из 11 доменов. В числе авторов — исследователи из Stanford, Carnegie Mellon, UC Berkeley и других организаций.

Claude Haiku 4.5 со Skills набрал 27.7% против 22.0% у Opus 4.5 без них!

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

Это работает в обе стороны: если у тебя Haiku или локальная модель, skills могут помочь компенсировать разницу в интеллекте. Для миллионеров, использующих Opus на повседневке, со Skills прирост ещё больше (+23.3%).

Сейчас мы как раз занимаемся разработкой Spring Skills. Один из скиллов называется spring-explore.

Зачем он?

Перед задачами, где нужно сначала разобраться в проекте, этот skill помогает агенту собрать первичный контекст о Spring Boot-приложении. Прежде чем браться за задачу, агент должен понять контекст: стек, модульную структуру, доменные сущности, репозитории, сервисы, DTO, мапперы и REST-слой. Потому что без явного сценария модели исследуют проект хаотично: лезут не туда, смотрят лишнее, тратят время, токены и tool calls на всё подряд.

Внутри spring-explore исследование разбито на этапы:

☑️ сначала агент по запросу предсказывает, какие сущности и компоненты вообще могут быть затронуты
☑️ затем выбирает только релевантные пути исследования
☑️ после этого строит конкретный план MCP-вызовов, выполняет его
☑️ и на выходе собирает exploration report с implicit assumptions.

Каждый этап жёстко ограничен: что смотреть, что пропускать и когда вообще не нужно вызывать инструменты. А вся проектная информация в исследовательском цикле должна собираться через Spring MCP: получить описание сущности, найти репозитории, сервисы, контроллеры, мапперы, DTO и другие связанные компоненты.

Все Spring Skills опубликованы на GitHub, поэтому давайте пробовать, пишите фидбек и не забывайте ставить звёздочки ⭐️

👩‍💻 Kotlin переходит к деструктурированию по именам

В Kotlin деструктурирование выглядело так: val (name, age) = person. Но компилятор берет значения не по именам, а по позиции component1/component2.

Отсюда проблемы. Если поменяли порядок параметров в data class или сделали age вычисляемым свойством: то та же строка начинает доставать другое поле. Причем иногда код даже скомпилируется, но, конечно, смысл изменится: val (age, name) = person.

И вот теперь Kotlin экспериментально переводит круглые скобки на деструктурирование по имени. Синтаксис будет такой: (val name, val age) = person. И порядок внутри скобок не важен. Переименование явно: (val years = age, val theName = name) = person.

Позиционное же деструктурирование остается, но переезжает в квадратные скобки для Pair/Triple и коллекций: val [x, y] = point.

Сейчас этот функционал является экспериментальным, но есть планы в будущем переехать полностью на деструктурирование по имени.

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

⚡️ Spring Agent Toolkit: ультимативный набор для вашего AI-агента

На прошлой неделе мы рассказывали про Spring Skills — набор инструкций для AI-агентов под Spring-разработку. Их можно использовать отдельно, но они также входят в состав Spring Agent Toolkit.

Помимо Skills, в Toolkit есть Spring MCP, разработанный командой Amplicode — сервер, который отдаёт агенту структурированную информацию о проекте прямо из IDE: бины, сущности, эндпоинты, зависимости.

Ниже — лишь малая часть доступных функций Spring MCP:
– list_spring_beans_tool, list_all_domain_entities, list_project_endpoints — список бинов, сущностей и эндпоинтов, в том числе в библиотеках и стартерах
– get_bean_injection_info, get_entity_details, get_endpoint_info — доступ к структурированной информации о связях бина и структуре сущностей
– create_migration_script — генерация миграционных скриптов
– read_class_file — доступ к содержимому файлов в зависимостях

А вот некоторые из Spring Skills:
– Spring Planning — создаёт структурированный план реализации с интерактивным сбором контекста, выбором архитектуры и декомпозицией задач
– Spring Explore — исследует приложение Spring Boot и формирует контекст проекта: технологический стек, структуру модулей, доменные сущности, REST-эндпоинты
– Spring Data JPA — правила и рекомендации по работе со Spring Data JPA: создание и изменение сущностей, репозиториев, проекций и транзакционного кода
– CRUD REST Controller — создаёт Spring REST-контроллер с CRUD-эндпоинтами
– Java Debug — отладка приложений через отладчик IntelliJ IDEA: брейкпоинты, debug-сессии, пошаговое выполнение, вычисление выражений, инспекция состояния во время выполнения

В будущем мы планируем развивать набор Spring Skills вместе с командой Amplicode.

📎 Подробнее про Spring Agent Toolkit читайте в новой статье на Хабр: https://habr.com/ru/companies/haulmont/articles/1034688/

🤩 Контроль API без боли: ArchUnit, Gradle и правила для библиотек

В Netflix тысячи Java-репозиториев. Когда в библиотеку вносят изменение, часть пользователей может перестать собираться или начать работать некорректно. Чаще всгео эта проблема возникает потому, что public контракты являются public только для авторов библиотеки, а не для пользователей.

Ребята из Netflix ввели простые метки для API: @Public - можно использовать снаружи, @Experimental - тоже можно, но интерфейс может меняться, @Deprecated - готовится к удалению. Все остальное считается внутренним и использованию извне не подлежит. Но сами аннотации проблему не решают, нужна проверка на масштабе.

Решение - ArchUnit + Nebula ArchRules.

ArchUnit анализирует скомпилированный байткод, поэтому одинаково работает для Java/Kotlin/Scala и проверяет реальный код на classpath. Команды пишут правила (например: «вне пакета библиотеки нельзя зависеть от ее deprecated/internal API»), публикуют их как отдельный arch-rules JAR, а runner автоматически запускает проверки в репозиториях и делает отчеты с точной строкой нарушения.

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

🧂 Соль и перец в безопасности паролей

Безопасность данных сегодня стала главным приоритетом для любого веб-ресурса. Базовым стандартом защиты учетных записей является хеширование паролей. Этот процесс превращает конфиденциальные символы в необратимый код. Без него утечка базы данных мгновенно скомпрометирует пользователей.

Однако обычного хеширования недостаточно из-за угрозы быстрых хакерских атак. Для защиты разработчики применяют «соль» (salt) — случайные данные, добавляемые к паролю. Минус соли в том, что она хранится рядом с хешем и не спасает от мощного перебора. Тогда на помощь приходит «перец» (pepper), скрытый в коде сервера. Его главная проблема — высокий риск потерять доступ ко всем аккаунтам при компрометации самого секретного ключа.

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

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

👩‍💻 Java — быстрая. Ваш код может таким не быть

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

- Конкатенация строк в циклах
- String.format() в горячем коде
- Автобоксинг

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

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

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

🤫 Оказывается, документация Claude Code рассказывает не всё

Стоило только лишь заглянуть в исходники. И вот, например, что можно настроить, но чего нет в доке:

— hooks, которые переписывают команды на лету;
— автоодобрение safe-команд без лишних подтверждений;
— постоянная память агентов между сессиями;
— auto-mode, который понимает описание окружения на обычном английском;
— самообучающиеся циклы памяти и «снов»;
— скрытые поля skills, agents и permissions, которых нет в документации.

И все это работает уже сейчас, а исходники-то Claude Code лежат у вас в node_modules.

Мы собрали все в статью. Там больше конкретики, JSON-конфигов, shell-хуков и примеров, которые можно утащить себе почти без правок.

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

Axelix. Элитный спецназ для Вашей Spring Boot экосистемы.

Друзья, на JPoint мы обещали анонс продукта с Open Source ядром, который помогает в разработке, тестировании и отладке Spring Boot приложений. И мы это сделали 😎.

Конечно же, речь про Axelix.

И на днях, наконец, состоялся первый Milestone релиз! GA релиз Axelix состоится летом 2026 года.

В этот воскресный вечер представляем Вашему вниманию статью Михаила, где он поясняет, в чём заключается цель проекта Axelix, какие проблемы он призван решить, и почему не Spring Boot Admin.

Приятного чтения!

📎 Ссылка на статью: https://habr.com/ru/companies/spring_aio/articles/1041836/

🔮 Перевополщение Stable Values в JDK 26

Ленивая инициализация в Java почти всегда значит: поле сначала null, потом double-checked locking, volatile, синхронизация. Ошибиться легко, а final не поставить. Итог - код хрупче и JVM хуже делает constant folding.

В JDK 26 (preview, JEP 526) добавили LazyConstant<T>: final поле, рецепт вычисления через Supplier, значение доступно через get(). Supplier выполнится при первом get и только один раз успешно, даже при гонке потоков. Кроме этого значение помечается как @Stable - JVM может считать его константой и агрессивнее оптимизировать.

Граничные случаи: null нельзя; не сериализуется; исключение из Supplier пробросится и следующая попытка снова пересчитает; equals у LazyConstant - только identity.

Для 1:n есть List.ofLazy и Map.ofLazy: элементы/значения считаются по индексу/ключу по требованию и кэшируются.

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

G1 хотят сделать GC по умолчанию вообще везде. Даже там, где JVM раньше выбирала Serial.

Это важное, но на первый взгляд не самое громкое изменение в HotSpot.

Сейчас логика такая:
— в серверных сценариях JVM уже давно по умолчанию выбирает G1;
— в более ограниченных средах, например с небольшим объёмом памяти или малым числом CPU, JVM могла выбрать Serial GC.

Теперь так:

если вы явно не указали GC, HotSpot всегда выбирает G1.

Почему так решили?

Когда G1 сделали дефолтным для серверных окружений в JDK 9, у Serial оставались заметные плюсы в более узких конфигурациях — по throughput и memory footprint. Поэтому JVM сохраняла отдельную ветку выбора для “маленьких” сред.

Но с тех пор G1 сильно подтянули:

— по пропускной способности он уже близок к Serial;
— по паузам он давно выглядит лучше;
— по потреблению нативной памяти тоже стал гораздо конкурентоспособнее.

То есть аргумент “в ограниченной среде по умолчанию нужен именно Serial” уже не выглядит таким железным.

Что это значит на практике?

— поведение JVM станет предсказуемее;
— дефолтный GC больше не будет зависеть от того, сколько у вас CPU и памяти;
— разбирать поведение приложения и JVM станет проще.

При этом важно:

— Serial никуда не исчезает;
— если он лучше подходит вашему кейсу, его по-прежнему можно указать явно;
— речь не о том, что Serial плохой, а о том, что G1 теперь достаточно хорош, чтобы быть разумным дефолтом везде.

Конечно, это не революция, но признак зрелости G1:
из дефолта для серверов он превращается в универсальный baseline для HotSpot.

❓А вы вообще в проде/локально полагаетесь на GC по умолчанию или всегда фиксируете его флагами?

👻 Проблема фантомной записи

В проде бывает так, что одна и та же операция часто повторяется: клиент не дождался ответа и ретраит, балансер порвал соединение, очередь переиграла сообщение. Вспоминаем про идемпотентность - это правило «повтор не должен создавать новый платёж/заказ».

Чтобы отличать повтор от новой операции, используют idempotency key (ключ идемпотентности). Это обычная уникальная строка-идентификатор, которую клиент или апстрим отправляет вместе с запросом (часто в заголовке `Idempotency-Key`). Сервис сохраняет этот ключ у себя и связывает с результатом операции.

Далее приходит запрос с тем же ключом - сервис не выполняет бизнес-действие второй раз, а дедуплицирует на основе ключа идемпотентности. Но так ли всё просто? Многолетний опыт анализа инцидентов показал, что на практике большое количество систем всё же регулярно допускают дублирования, хотя делали всё по методичке.

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

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

🫡 Блеск и нищета

Именно так называется наша первая статья, вышедшая ровно 2 года назад.

Вот она: Блеск и нищета нового Scrolling API в Spring Data

За все время мы выпустили 248 статьей. И вот небольшая статистика по ним:

📎 Самая просматриваемая статья (111к просмотров) и самая комментируемая (130 комментов): Как жить без IntelliJ IDEA? Часть №1. Собери сам

📎 Самая залайканная статья (64 лайка): OpenIDE: первая российская среда разработки с поддержкой Java 24

📎 Самая заминусованная статья (-13 голосов): REST умер? Почему Java-разработчики уходят в GraphQL

📎 Собравшая наибольшее количество сохранений в избранное (251 сохранение): Как подготовиться и пройти System Design Interview

📎 Самая дочитываемая статья: Hibernate merge: начали за здравие, закончили за упокой

Давайте обсудим в комментариях, чего нам не хватает, а чего наоборот, слишком много. Будем рады фидбеку!

Спасибо всем за все! 💚