Spring АйО

🖥 Ваш JSONB тормозит не из-за базы. Возможно, виноват Hibernate Когда Hibernate начинает проседать по производительности, первым делом обычно ищут лишние SQL-запросы. Тем не менее, с JSON или JSONB проблема может скрываться совсем в другом месте. Hibernate способен незаметно выполнять дорогую работу с JSON-объектами, даже когда вы этого не ожидаете. На небольших объёмах это почти не видно, а под нагрузкой превращается в серьёзный bottleneck. Хорошая новость состоит в том, что часто проблема решается довольно просто, и хватает всего пары аннотаций, чтобы сократить время обработки почти вдвое. 🔗 Что именно происходило и как это исправить: https://habr.com/ru/companies/spring_aio/articles/1075156/

Спека вместо кода: OpenSpec vs SpecKit Сколько строк сгенерированного кода вы реально прочитали за последнюю неделю? Вопрос неудобный, и именно из него растёт spec-driven development: описываем намерение явно, до генерации, и агент работает по спеке, а не по вашей интуиции. Новая статья на Хабре — сравнение OpenSpec и SpecKit: два взгляда на один процесс, разные компромиссы между простотой и контролем качества. Ну и конечно же: как OpenIDE Pro помогает работать со спеками на практике? 👉 Читаем тут

👩‍💻 В 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 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

🍃 AI пишет лучше разработчиков, Баг в JVM сломал Kafka, JavaScript победил Java | Spring АйО Подкаст №70 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО 🥰 СМОТРЕТЬ НА RUTUBE 🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях

🧑‍💻 Победить Hibernate в тестах. Сможем? В рамках первого потока Spring АйО Акакдемии был поднят интересный вопрос:

Возможно ли, каким-то образом, обнаружить в процессе тестирования, что Hibernate под капотом делает что-то страшное?

На деле вопрос очень интересный и практичный. Мы решили оформить его в небольшую статью в виде размышлений о том, какие вещи, в теории, можно попробовать. Данная статья не является исчерпывающим материалом, а больше аккамулирует опыт и рассказывает - что, на практике, имеет смысл, а что не очень. На деле, одними тестами тут обойтись будет тяжело. Лучше всего использовать комбинированный подход. 😎 Приятного чтения! 📎 Статья на Хабр: https://habr.com/ru/companies/spring_aio/articles/1068176/

⚡️ Можно ли запретить AI-агенту ломать архитектуру Spring-приложения? Одних инструкций в AGENTS.md и Skills недостаточно. Агенту нужны инструменты, которые проверят результат и помогут найти ошибку.

В новом видео разбираем это на примере ArchUnit: агент нарушит архитектуру Spring-приложения, получит упавший тест и самостоятельно исправит код.

Но видео не про ArchUnit. Оно про то, как тесты, линтеры и анализаторы создают для AI-агента обратную связь и помогают ему работать качественнее. 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО 🥰 СМОТРЕТЬ НА RUTUBE