Всем привет! ???? Мы Java-разработчики Т-Банка: Андрей, Арсений, Роман и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

У Spring за один день вышел 91 CVE — больше, чем за весь прошлый год, — и нашел их в основном AI-сканер. Oracle впервые за двадцать лет выпустила патч безопасности вне квартального цикла. А еще уже совсем скоро (15 сентября) выходит JDK 27. Обо всем этом и не только рассказываем в свежем выпуске ?

Горячие JEPs

? JEP 401: Value Objects. Valhalla доехала до превью, и == больше не про ссылки. JEP 401 и парный к нему JEP 539 перешли в статус Integrated: код влит в mainline и value-типы уже можно потрогать в EA-сборках JDK 28 с флагом --enable-preview. Для value-объектов «==» перестает быть сравнением ссылок и становится сравнением состояния. True, если это один и тот же класс и все поля совпадают. Вечный вопрос с собеседований про Integer, и «==» скоро придется переформулировать.

? JEP 540 Proposed to Target JDK 28 with a Simple JSON API. В JDK 28 в рамках JEP 540 планируют добавить собственный простой API для работы с JSON. Он позволит парсить, читать и генерировать JSON без сторонних библиотек, но при этом предоставляет только базовые операции с JSON, не претендует на замену Jackson или Gson. Пока API будет поставляться как incubator-модуль jdk.incubator.json, поэтому его устройство еще может заметно измениться по итогам обратной связи.

? JEP 535: Shenandoah GC — Generational Mode by Default. В JDK 28 generational-режим Shenandoah планируют сделать режимом по умолчанию. Generational Shenandoah делит heap на молодое и старое поколения и опирается на классическую гипотезу о том, что большинство объектов умирает вскоре после создания. Благодаря этому сборщик может чаще работать с молодым поколением, вместо того чтобы каждый раз рассматривать всю кучу.

Сам generational-режим уже не экспериментальный: ранее его довели до production-ready-состояния, а теперь OpenJDK делает следующий шаг. При запуске с -XX:+UseShenandoahGC будет использоваться именно generational-вариант, а старый non-generational-режим пометят deprecated с намерением в будущем удалить совсем.

Главные новости

? Первый ежемесячный патч безопасности состоялся. 18 августа Oracle выкатила первый Critical Security Patch Update. Всего 943 патча. Сентябрьского CSPU не будет, следующая точка — квартальный CPU 20 октября, и его обещают крупнее обычного. Зачем все это, хорошо объясняет JVM Weekly: июльский CPU содержал 1 448 патчей — рекорд за всю историю — при 309 годом ранее.

? 91 CVE в Spring за один день. 20 августа Spring опубликовал 91 security advisory: 1 critical, 17 high, 55 medium, 18 low. Для сравнения: за весь 2025 год Spring выпустил 16 CVE. Конечно, это результаты AI-анализа. Sonatype насчитала 148 608 затронутых компонентов.

И для некоторых это очень-очень больно.

У Spring две линии поддержки: бесплатная OSS и платная коммерческая. Пока ветка живая, фиксы выкладываются в открытый доступ и достаточно подтянуть версию в pom.xml. Когда OSS-поддержка заканчивается, публикация в открытый канал прекращается, а патчи для этой ветки продолжают выходить только для платных подписчиков коммерческой поддержки Broadcom (ну или сторонних вроде HeroDevs).

У Spring Boot 3.5 бесплатная поддержка закончилась 30 июня 2026. А 20 августа вышли 91 advisory. Раскрытие публичное, то есть все, включая атакующих, узнали про уязвимости одновременно. Но человек, который сидит на 3.5, обновиться бесплатно не может: исправленных версий для его ветки в открытом доступе просто не появится. У него остается два выхода, оба не дешевые: мигрировать на 4.x или покупать коммерческую поддержку. 

• Разбор от HeroDevs

• Разбор от Sonatype

? Постквантовая криптография поедет в LTS-ветки. Oracle опубликовала график релиза постквантовой криптографии. ML-KEM и ML-DSA уже в JDK 25, в 21 и 17 приедут в октябре 2026, в 11 и 8 — во второй половине 2027. Гибридный обмен ключами для TLS 1.3 добавят в JDK 25 в октябре 2026, в 21 и 17 — в первой половине 2027. 

Расчет на то, что приложения, которые полагаются на TLS-стек самой Java, получат квантовую устойчивость путем обновления и установки конфига, а не переписывания кода.

Интересные видео

? The Power of JDK Flight Recorder. Доклад Микаэля Видстедта с JavaOne про JFR как встроенную в JDK observability, которую можно держать включенной постоянно. Разбирается механика событий, сбор телеметрии и три класса задач: деградация производительности, утечки памяти и проблемы с потоками. Показываются конкретные сценарии диагностики с живыми демо — пошаговые алгоритмы по поиску причины неисправности.

? Inside Java Newscast #114: JSON API, Valhalla Progress, LTS ❤️ PQC. Первый выпуск в новом ежемесячном формате: раньше Newscast выходил раз в две недели, теперь — раз в месяц. Три темы августа: JEP 540 и его путь к JDK 28, прогресс Valhalla с влитыми PR и превью в EA-сборках, план бэкпорта постквантовой криптографии в LTS-ветки.

Полезные статьи

? Vibe Coding, Maven, and the Dependencies You Didn't Choose. Перевод Стива Пула о том, что при вайбкодинге поставщиков софта выбирает не человек. Ассистент правит pom.xml, добавляет плагины и тянет транзитивные зависимости, которые никто сознательно не одобрял, а Maven-плагины опаснее обычных библиотек, потому что выполняют код прямо во время сборки. Отдельный сюжет — данные Expel про группу, которая теми же инструментами генерирует малварь и аудирует сама себя на предмет обнаружения.

? Как мы победили OOMKill и сэкономили треть ресурсов: настройка JVM в Kubernetes. Разбор, почему Java-приложения в Kubernetes любят падать с OOMKill, долго стартуют и странно утилизируют ресурсы. Автор раскладывает память JVM по составляющим, показывает влияние различных GC и приходит к интересным (̶х̶о̶л̶и̶в̶а̶р̶н̶ы̶м̶) выводам: JVM любит много ресурсов и переход к множеству слабых подов в сравнении с меньшим числом мощных выигрывает. Цифры по итогам: минус 18% памяти и минус 31% CPU, притом что производительность выросла.

? Не подавать холодным! Прогрев JVM перед запуском трафика. После каждого релиза сервис несколько минут отвечал медленнее: Kubernetes пускал боевой трафик на под раньше, чем JIT успевал разогреться, а GC в этот момент давал длинные паузы. Решение — этап прогрева в ApplicationRunner, где сервис до подключения к трафику сам шлет себе тестовые запросы. А у вас есть такие проблемы?

? Project Loom in IntelliJ IDEA. Обзор того, что IDE научилась делать с Loom. Начиная с 2026.1 виртуальные потоки, форкнутые внутри StructuredTaskScope, группируются в thread dump по скоупам, то есть в дампе видно родительско-дочернюю структуру задач, а не плоскую простыню. Есть live template sts для быстрого скаффолдинга скоупа, распознавание конфигураций Joiner и таймаутов и языковая поддержка ScopedValue.

? Value Classes Still Need Compiler Sympathy. Отрезвляющая статья для тех, кто в будущем хочет перевезти все на value. Йохан Шёлен показывает, что value-класс сам по себе ускорения не гарантирует, и одна и та же структура может оказаться быстрее во flattened-виде для одних методов и в ссылочном для других.

? Две аннотации Hibernate, которые вдвое сократили время обработки JSON.

Перевод поста с разбором интересного кейса по оптимизации работы Hibernate c JSON-полями. Во время профилирования работы всего с 5 записями было обнаружено, что потреблялось неадекватно много ресурсов (как по CPU, так и по RAM) на следующие операции:

• Dirty checking в Hibernate (6 087 CPU-семплов, 34% нагрузки)%

• GC (4 397 CPU-семплов, 25% нагрузки)%

• deepCopy в Hibernate (2 361 CPU-семплов, 13% нагрузки).

В статье два ценных момента. Первый: в ней по шагам расписывается, как именно была выявлена и исправлена проблема. Второй: дополнительное напоминание о том, что при работе с Hiberanate (да и с любым инструментом) всегда надо анализировать, как конкретное приложение работает с данными, и тюнить инструмент под него. 

? Победить Hibernate в тестах. Возможно? Статья отвечает на вопрос «Можно ли в тестах как-то проверить, что Hibernate под капотом делает что-то страшное?».

Сначала автор определяется с понятиями. «Страшное» означает неожиданное поведение Hibernate, которое приводит к проблемам. Потом он категоризирует проблемы:

• На уровне ORM. Это проблемы на уровне Hibernate, например пагинация в памяти приложения, что может привести к переполнению хипа. Тут имеет смысл смотреть на логи. Конкретно эту проблему Hibernate подсвечивает, и ее можно так отловить.

• На уровне приложения. Это проблемы, вызванные криворукостью неправильным использованием инструмента. В пример приводится N + 1. Отследить такие проблемы сложно и лучше использовать для этого специальные анализаторы.

Отдельно рассматривается пример проблемы, которую все же в тестах отловить можно, если использовать Statistics API. С его помощью можно убедится, что Hibernate под капотом совершит только те запросы, которых мы от него ожидаем. Например, только один INSERT без кучи дополнительных UPDATEs и DELETEs.

Константин Максимов

Насчет тестов нужно, думаю, отдельно проговорить, что не стоит писать на каждое сохранение каждой сущности подобные тесты. Мне видится 2 адекватных кейса для подобных тестов. Первый: мы по опыту знаем, что в таком-то месте лучше перебдеть и добавить дополнительных проверок. Например, у конкретной сущности есть связи и они в нашем приложении как-то хитро менеджатся. Второй: у нас такого опыта еще не было либо недоглядели и словили соответствующий баг на проде. Тогда пишем тест в контексте исправления бага.

? Preparing for Change: Safe Switching over Sealed APIs. Интересная тонкость про sealed-типы и exhaustive switch. Компилятор гарантирует, что switch покрывает всех наследников sealed-типа, которых он знает в момент компиляции. Но, если тип находится во внешней библиотеке, ее автор может выпустить новую версию и добавить еще один permitted subtype. Если после этого просто запустить приложение со свежей библиотекой без перекомпиляции, старый switch при встрече нового типа может упасть с MatchException. 

Авторы статьи советуют не пытаться заранее лечить проблему обычным default: так можно, наоборот, спрятать изменение контракта API и лишиться полезной проверки компилятора после обновления зависимости.

? JDK 27 and JDK 28: What We Know So Far. Обзор уже сформированного набора изменений JDK 27: в релиз вошли девять JEP, а сама Java 27 должна выйти 15 сентября 2026 года. Заодно автор заглядывает немного вперед и разбирает JEP, которые уже нацелены на JDK 28, а также несколько кандидатов, которые потенциально могут в него попасть.

Любопытные подкасты

?️ Podlodka #490 – AI-агенты Deep Dive. В этом выпуске Вадим Бриллиантов, создатель фреймворка для AI-агентов Koog, подробно рассказывает о том, как устроены современные AI-агенты, из каких частей они состоят и какие есть архитектурные подходы к построению агентов. Отдельно разобрали особенности кодинг-агентов. Особое внимание уделялось вопросу, можно ли харнес, собранный одной моделью, использовать в работе с другой. 

? Spring АйО. Подкаст #70. AI пишет лучше разработчиков, баг в JVM сломал Kafka, JavaScript победил Java. Ведущие рассуждают о том, почему в Java крупные фичи вроде Valhalla делаются десятилетиями и почему AI-агенты пока не тянут понимание проекта целиком. А еще подробно разбирается история одного сбоя, где баг в JVM в связке с особенностями Kafka положил прод.

? Spring АйО. Подкаст #71. ИИ придумал уязвимости, IDE все еще нужна, Spring Boot vs Quarkus. Выпуск о том, что AI сделал с безопасностью. Хорошая новость: уязвимости стали находить намного быстрее. Плохая: их научились и выдумывать, причем выдуманные спокойно доезжают до официальных баз с солидным рейтингом критичности. Еще поговорили о том, нужна ли IDE, если есть агент и терминал и стоит ли вообще переживать из-за времени старта Spring Boot.

? Inside Java Podcast #68: Operator Overloading with Type Classes. Джо Дарси, разработчик Valhalla, обсуждает с Николаем Парлогом перегрузку операторов для кастомных числовых value-типов. Это когда свой тип для комплексных чисел или денег складывается через +, а не через add(). Важное разграничение: произвольного определения операторов в Java не будет почти наверняка, обсуждается именно ограниченный механизм, привязанный к value-типам.

Просто интересное

? The AI-Native SDLC playbook. Anthropic выпустили гайд по внедрению AI во все стадии SDLC-пайплайна — от планирования до поддержки. Для каждой стадии приведены подробные разъяснения процесса, явно сравнивается традиционный подход с AI-native-подходом, указываются конкретные инструменты (разумеется, от компании Anthropic ?) и разбираются риски.

Центральные тезисы:

• Ботлнек сместился с написания кода на другие процессы. Мы получили буст в скорости написания кода, но без прироста ускорения других процессов это не дает ощутимого выигрыша. 

• Линейный процесс заменяется на циклический. Как в контексте конкретной стадии, так и всего пайплайна. После деплоя агент следит за состоянием релиза, а при возникновении проблем предлагает решение, формирует новый интент, который заново проходит по всем стадиям. 

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

Кстати, JUG Ru как раз открыли доступ к плейлисту JPoint 2026: AI-Powered SDLC.

Константин Максимов

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

? Java Was Optimized for LLMs Decades Before They Existed. Адам Биен утверждает, что Java случайно оказалась оптимизирована под языковые модели за десятилетия до их появления. Явные типы, многословность, жесткие соглашения об именовании и стандартизированные аннотации дают код с очень малым числом степеней свободы, а это идеальный материал и для обучения, и для генерации.

? Code at Court: Java as Evidence. Жанр, который сложно себе представить: исходники и артефакты сборки работают в качестве доказательства в суде. Разбирается авторское право на код и дыра с AI-сгенерированным кодом, у которого изначально нет правообладателя, потому что модель не является физическим лицом. Еще в выпуске говорят про доказательство целостности через GIT с криптографическими хешами, про восстановление читаемого кода из байткода через CFR, про борьбу с обфускаторами.

? The Economic Benefit of Refactoring. Эксперимент о том, как рефакторинг влияет на стоимость разработки с AI-агентами. Автор последовательно рефакторил огромный 17-тысячестрочный Rust-файл и после каждого шага просил агента выполнить одну и ту же задачу. По результатам рефакторинга потребление входных токенов сократилось на 83%.

Андрей Орлов

Эксперимент очень интересный, и, как мне кажется, его можно проецировать и просто на когнитивную нагрузку разработчика без AI. Чем лучше структурирован код, тем меньше мы сжигаем „входных токенов“ в своем мозгу

? Jakarta Agentic AI 1.0: AI-агенты становятся частью Jakarta EE. У Jakarta Agentic AI появился первый milestone — 1.0.0-M1. Это попытка стандартизировать разработку AI-агентов в Java-мире: вместо привязки приложения к конкретному LangChain4j, Spring AI или SDK конкретного LLM-провайдера Jakarta предлагает общий API для создания и запуска агентов внутри Jakarta EE.

Джавовые события

Прошел JVM Day. 29 августа в Москве, семь докладов — от бенчмарков и mechanical sympathy до автоматизации миграций через OpenRewrite. Записи участникам разошлют в течение двух недель, в открытый доступ они выйдут позже. Следите за анонсами ?

Joker тем временем выложили программу: около тридцати докладов, часть слотов пока помечена как секретный доклад. Тема года заявлена как «Агенты. Философия. Java». Ждем 14—15 октября.

IntelliJ IDEA Conf 2026, 8—9 сентября, онлайн и бесплатно. В программе новые возможности IDEA, AI-инструменты, улучшения Java/Kotlin-разработки и практические доклады команды JetBrains и приглашенных экспертов.

Свежие релизы

? Spring AI 2.0.1. Больше 80 закрытых issue по фидбэку от команд в проде. ToolCallingAdvisor получил лимит числа tool-вызовов на запрос, то есть защиту от бесконечных агентских вызовов. PagePdfDocumentReader теперь принимает диапазоны страниц. Закрыто 7 CVE.

? Quarkus 3.39. Постквантовая криптография в TLS registry для HTTP-сервера, клиентов и mailer через три новых свойства, включая режимы strict, client-negotiated и relaxed. Reflection-free-сериализаторы Jackson откатили обратно в opt-in из-за проблем со стабильностью перед LTS. Команда прямо пишет, что релиз легкий, потому что силы ушли в Quarkus 4, который целится в ноябрь.

? Keycloak 26.7.1 и 26.7.2. В сумме 20 закрытых уязвимостей, включая эскалации в fine-grained admin permissions, обход авторизации через нормализацию URI и выдачу расшифрованных client secrets через Admin REST API.

? Spring Boot 4.2.0-M1. Вышел первый milestone Spring Boot 4.2. Из заметного:

• поддержка AMQP 1.0 и RabbitMQ-специфичных возможностей;

• image-based build cache для Cloud Native Buildpacks;

• обновления зависимостей, документации и пачка исправлений.

Всего в релиз вошло больше сотни изменений. Пока это ранняя версия для знакомства с будущим Spring Boot 4.2.

? Gradle 9.7. Главное нововведение Gradle 9.7: Isolated Projects перешел из experimental в incubating. Он позволяет:

• изолировать конфигурацию отдельных subprojects;

• конфигурировать несколько проектов параллельно;

• в перспективе пропускать конфигурацию неизменившихся проектов.

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

Спасибо за прочтение! Ждем обратную связь в комментариях. Увидимся через месяц ?

Присылайте материалы, если встретили что-то интересное, — опубликуем в следующем выпуске!