ИИ-ревьюер на Spring Boot превращает ответ модели в замечания к коду

Отправить diff модели — только начало. Чтобы результат оказался полезен на ревью, нужно связать каждое замечание с файлом, местом в коде и объяснением проблемы.

Автор CodeGuard AI описывает такой процесс на Java и Spring Boot: получить данные PR и изменения, собрать контекст, добавить правила проверки, разобрать ответ модели и подготовить ревью в GitHub.

Замечания хранятся в структурированном виде: что найдено, где, насколько серьёзно и насколько уверена модель. Провайдер вынесен за отдельную абстракцию — можно переключаться между OpenAI, Gemini и Ollama.

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

#java #springboot #codereview

Helidon 27 переносит контекст с ThreadLocal на ScopedValue

Идентификатор запроса и другие данные контекста нужны в разных слоях приложения. При передаче через ThreadLocal важно правильно задать и завершить их жизненный цикл.

В Helidon 27 активный контекст фреймворка перенесли на ScopedValue. Значение привязано к ограниченной области выполнения, что помогает согласовать время жизни контекста с работой, для которой он нужен.

Использовать более новые механизмы Java позволило повышение базовой версии: Helidon 27 требует JDK 27.

Одновременно проект разделяет две линии развития. Helidon 27 — актуальная ветка с новыми возможностями, а Helidon 4.5 остаётся LTS-веткой для команд с более длинным циклом проверки и обновления.

Поэтому переход стоит планировать вместе с обновлением JDK и проверкой зависимостей сервиса.

#java #helidon #jvm

В JDK 28 готовят простой JSON API для небольших задач

Прочитать JSON-конфигурацию, достать вложенное значение и сформировать небольшой документ — для таких случаев в JDK готовят собственный API разбора, навигации и генерации JSON.

В докладе Everyday JSON in Java Алан Бейтман и Виктор Кланг объясняют, какие задачи он должен закрыть и как подход с ориентацией на данные повлиял на устройство API.

Основной сценарий — простая работа с документом без подключения внешней библиотеки. Авторы отдельно подчёркивают: заменять существующие JSON-библиотеки целиком не планируют.

Для проекта с настройками сериализации, модулями Jackson и преобразованием сложных объектных моделей появление нового API ещё не означает готовой замены.

Для JDK 28 API готовится в статусе incubator. Интерфейс ещё может меняться; стабильной возможностью JDK 27 он не является.

#java #json #jdk28

Pi4J 5 позволяет подменять оборудование при разработке на обычном компьютере

Код для GPIO и датчиков неудобно разрабатывать, если плата должна постоянно лежать рядом. В готовящейся Pi4J 5 добавили возможность использовать реальное оборудование, когда оно доступно, и переходить на заглушки на других системах.

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

Заодно команда упрощает API создания устройств: конфигурация собирается через newConfigBuilder() соответствующего типа, затем передаётся в context.create(...). Завершение работы тоже сводят к одному close().

Pi4J 5 пока находится в разработке, доступны snapshot-сборки. Дата финального релиза не объявлена, поэтому изменения API стоит учитывать до переноса рабочего проекта.

#java #pi4j #iot

Spring Tools 5.4 предлагает исправления для аннотаций контроллеров и тестов

Некоторые сочетания аннотаций Spring можно выразить короче и точнее. В Spring Tools 5.4.0 добавили проверки и быстрые исправления для перехода к @RestController, @SpringJUnitConfig, @ApplicationModuleListener и специализированным аннотациям области видимости.

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

Команда также ускорила ряд быстрых исправлений и проверку версий по репозиториям, улучшила надёжность индексации исходников. Дистрибутив для Eclipse обновили до Eclipse 2026-09.

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

#java #spring #инструменты

Payara Community убирает требование повышенных прав для SSH-узлов

В Payara Community 7.2026.10 управление SSH-узлами больше не требует повышенных прав. Для домена на нескольких хостах это упрощает настройку учётной записи, через которую сервер работает с удалённым узлом.

SSH-доступ и необходимые разрешения остаются нужны. Изменение убирает требование избыточных привилегий.

Ещё появились две команды asadmin для управления конфигурацией: delete-jvm-option и delete-system-properties. Исправлены проблемы с конкурентным развёртыванием и запуском приложений после перезапуска домена.

Ветка Community 7 остаётся на Jakarta EE 11 и MicroProfile 7.1. В статье отдельно перечислены обновления коммерческих веток Azul Payara — их исправления и возможности нужно сверять со своей редакцией.

#java #jakartaee #payara

Java-расширение Oracle разделяет JDK языкового сервера и проекта

Редактору может требоваться более новая Java, чем приложению. В Java Platform Extension от Oracle для VS Code эти настройки можно разделить.

jdk.jdkhome задаёт JDK языкового сервера и используется для проекта по умолчанию. А jdk.project.jdkhome позволяет выбрать отдельный JDK для сборки и запуска проекта.

Например, в настройках рабочего пространства:

{
  "jdk.jdkhome": "/opt/jdk-27",
  "jdk.project.jdkhome": "/opt/jdk-21"
}

Пути замените на свои. Самому расширению нужен JDK 21 или новее, при этом поддерживаются проекты на JDK 8 и выше.

Это пригодится, когда обновить инструменты уже можно, а приложение остаётся на прежней версии Java. Настройки Maven или Gradle при этом тоже нужно согласовать с выбранным JDK проекта.

#java #vscode #jdk

Testcontainers: одного withReuse(true) мало

Режим Reusable Containers оставляет контейнер работающим после тестов, чтобы следующий запуск мог использовать его снова. Но одного withReuse(true) в описании контейнера недостаточно.

Нужно разрешить reuse и в окружении: через TESTCONTAINERS_REUSE_ENABLE=true либо запись testcontainers.reuse.enable=true в пользовательском ~/.testcontainers.properties. Файл свойств в classpath для этого не подходит.

Контейнер запускают вручную через start(). Останавливать его нельзя ни прямым stop(), ни через try-with-resources или JUnit-интеграцию, которая завершит его за вас. При следующем запуске конфигурация должна совпадать.

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

Spring Boot: 20 секунд на фазу остановки

В настройке spring.lifecycle.timeout-per-shutdown-phase=20s легко прочитать обещание «приложение завершится за 20 секунд». Но это таймаут отдельной фазы остановки, а не общий лимит завершения процесса. Значение 20 секунд приведено в документации как пример.

Согласно справочнику Spring Boot 4.1.1, graceful shutdown включён по умолчанию для встроенных Jetty, Reactor Netty и Tomcat, в servlet- и reactive-приложениях. При закрытии контекста уже принятым HTTP-запросам дают время завершиться. Новые запросы эти серверы перестают принимать на сетевом уровне. При постоянных соединениях детали поведения могут отличаться.

Есть ловушка при проверке из IDE: кнопка Stop может оборвать процесс сразу, если среда не отправляет корректный SIGTERM. Поэтому сначала проверьте, какой сигнал получает приложение. Иначе принудительное завершение легко принять за ошибку в настройке graceful shutdown.

Bulkhead в Resilience4j: семафор или отдельный пул

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

SemaphoreBulkhead использует семафор и собственного пула не создаёт. В документации Resilience4j 2.2.0 у maxConcurrentCalls значение по умолчанию 25, у maxWaitDuration — 0. Первый параметр ограничивает одновременные выполнения, второй задаёт, сколько поток может ждать допуска, когда лимит исчерпан.

У FixedThreadPoolBulkhead есть собственный пул и ограниченная очередь. Здесь нужно согласовать размеры пула и queueCapacity. У семафорного варианта размер рабочего пула остаётся вашей заботой.

Такой лимит относится к конкурентным вызовам через конкретный bulkhead. Число запросов в секунду он не задаёт и пропускную способность внешнего сервиса не увеличивает.

Spring: событие опубликовано, обработчик не вызван

Событие опубликовано, исключений нет, а метод с @TransactionalEventListener не вызван. Сначала проверьте, была ли в момент публикации активная транзакция.

По умолчанию обработчик привязан к AFTER_COMMIT. При откате он не сработает. Если транзакции вообще нет, Spring пропустит вызов. Атрибут fallbackExecution=true явно разрешает обработку и в этом случае.

Здесь речь об обычной транзакции, привязанной к потоку. Выбор фазы связывает обработчик с её исходом, но не обеспечивает гарантированную доставку во внешнюю систему.

Transaction-bound Events в Spring
#spring #java

Gradle: сгенерированный checksum ещё нужно проверить

Команда ./gradlew --write-verification-metadata sha256 собирает контрольные суммы зависимостей. Файл gradle/verification-metadata.xml затем служит базой для проверки загружаемых артефактов.

При генерации этой базы Gradle доверяет тому, что уже доступно в репозиториях. Если JAR к этому моменту подменён, в базу попадёт checksum подменённого файла. Поэтому сгенерированные метаданные нужно проверить до принятия в проект.

Checksum подтверждает совпадение с доверенной базой. Он не ищет вредоносный код и сам по себе не устанавливает автора. Changing-зависимости, включая SNAPSHOT, и локальные артефакты этой проверкой не покрываются.

Руководство Gradle 9.7.0

Quarkus: три промаха кеша, один вызов метода

Несколько запросов одновременно обращаются к отсутствующему ключу. В Quarkus 3.27 с кешем на Caffeine аннотация @CacheResult обрабатывает такие обращения вместе: первый вызов вычисляет значение, остальные ждут результат.

Это работает в пределах одного кеша, одного ключа и одного экземпляра приложения. У объектов, входящих в ключ, должны корректно работать equals() и hashCode(). Разные ключи обрабатываются отдельно. Между экземплярами приложения такой блокировки нет.

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

При попадании в кеш тело метода не выполняется.

Кеширование в Quarkus 3.27

ResourceLock в JUnit: параллельный доступ на чтение

В параллельных тестах JUnit Jupiter @ResourceLock объявляет общий ресурс по строковому имени и режим доступа к нему.

Два теста с READ для одного ресурса могут выполняться одновременно. READ_WRITE конфликтует с любым другим доступом к тому же ресурсу. Для аннотации на тестовом методе блокировка захватывается до @BeforeEach и освобождается после @AfterEach.

Параллельный запуск нужно включить и задать режим выполнения, например через @Execution(CONCURRENT). Одного флага enabled для параллельного выполнения тестов недостаточно.

Это координация тестов Jupiter, объявивших один ресурс, а не блокировка между процессами ОС.

Parallel Execution и Synchronization

NMT в HotSpot: сначала включить, потом искать рост

Native Memory Tracking нужно включить при старте JVM, например флагом -XX:NativeMemoryTracking=summary. Если процесс уже работает без NMT, включить сбор через jcmd не получится.

После прогрева сохраните базу командой jcmd <pid> VM.native_memory baseline. Позже jcmd <pid> VM.native_memory summary.diff покажет изменения по категориям относительно неё.

NMT учитывает внутренние аллокации HotSpot, но не всю память стороннего native-кода. Рост категории даёт направление для диагностики, а не готовое доказательство утечки.

На карточке — команды из руководства Oracle Java 25.

Native Memory Tracking в HotSpot
#jvm #java

Micrometer: каждый новый 404 может раздувать метрику

Если в собственной инструментализации записывать сырой URI в тег метрики, запросы к /missing/a, /missing/b и тысячам других несуществующих путей дадут тысячи разных значений тега.

Micrometer разбирает именно такой пример: если не ограничивать значения URI для 404, кардинальность метрики растёт с каждым новым отсутствующим ресурсом. Вместо произвольного пути можно использовать ограниченное значение вроде NOT_FOUND.

Это задача проектирования собственных тегов. Из примера не следует, что все интеграции Spring Boot по умолчанию записывают сырые 404-пути.

На схеме меняется только тег URI. Значения условные, измерений памяти здесь нет.

Micrometer: Tag Values

Kafka: heartbeat не заменяет вызовы poll

Consumer может отправлять heartbeat и при этом слишком долго обрабатывать пачку. В Java-клиенте Kafka 4.0 прогресс проверяется отдельно: интервал между вызовами poll ограничивает max.poll.interval.ms.

Если интервал превышен, consumer рискует потерять партиции, а коммит может завершиться CommitFailedException. Размер пачки ограничивает max.poll.records. Увеличение интервала даёт больше времени на обработку, но может замедлить rebalance.

Если обработку вынести в worker, consumer должен продолжать вызывать poll. Auto commit отключают, партиции приостанавливают до конца обработки, а offsets коммитят вручную только после обработки. Сам KafkaConsumer не thread-safe: worker-потоки не должны произвольно вызывать его методы.

KafkaConsumer 4.0: Detecting Consumer Failures

StampedLock: читать поля можно до проверки, использовать — после

Оптимистическое чтение в StampedLock обходится без удержания read lock. Поток получает stamp через tryOptimisticRead(), копирует поля в локальные переменные и вызывает validate(stamp). Использовать прочитанные значения можно после успешной проверки.

Если за это время другой поток захватывал write lock, проверка провалится. В примере Oracle чтение повторяют уже под read lock. До проверки поля могут противоречить друг другу. При обходе изменяемого массива или вызове метода по прочитанной ссылке могут понадобиться дополнительные проверки согласованности данных.

Это механизм для коротких участков с известным устройством данных. StampedLock не реентерабелен, а его политика не гарантирует предпочтения читателям или писателям.

StampedLock, Java SE 25
#java

🔴 Завтра открытое собеседование с Java-разработчиком

4 ноября (уже завтра!) в 19:00 МСК приходи онлайн и посмотри, как проходит настоящее техническое интервью на Middle Java-разработчика.

Как это будет:

📂 Виктор Анохин, Java/Kotlin-разработчик Wildberries, ex-Билайн, проведёт собеседование с разработчиком-добровольцем: будет задавать реальные вопросы и давать задачи;

📂 Виктор прокомментирует каждый ответ и объяснит, на что обращает внимание интервьюер;

📂 В конце можно будет задать Виктору любой вопрос.

Виктор более 5 лет занимается enterprise-разработкой в финтехе, телекоме и e-commerce. Сейчас он ведущий разработчик банковских сервисов и системы лояльности в Wildberries. Ранее строил highload-микросервисы с нуля.

Участие бесплатное. Эфир проходит в рамках менторской программы ШОРТКАТ для Java-разработчиков, которые хотят вырасти в грейде и зарплате и прокачать технические навыки.

Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot

Реклама.
О рекламодателе.