В 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