LINUX.ORG.RU

Quarkus 3.36

 , , quarkus


0

2

Опубликован релиз Quarkus 3.36 — Java-фреймворка для cloud-native-приложений, ориентированного на контейнеры, Kubernetes, JVM и нативную компиляцию. Выпуск состоялся 27 мая 2026 года. Главные изменения связаны с новым экспериментальным механизмом обмена сигналами между компонентами, улучшениями supply chain security, TLS и OIDC-аутентификацией для zero-trust-сценариев.

Для обновления разработчики рекомендуют использовать свежую версию Quarkus CLI и выполнить:

quarkus update

Команда quarkus update, по заявлению проекта, умеет обновлять приложения до Quarkus 3.36 даже с веток Quarkus 2.x.

Основные изменения

  • Quarkus Signals — экспериментальное расширение для обмена сигналами между компонентами. В Quarkus появился новый механизм, позволяющий компонентам приложения взаимодействовать слабосвязанным способом: один компонент отправляет сигнал, другой его принимает. Разрешение получателей типобезопасное и вдохновлено CDI events: сигналы сопоставляются с обработчиками по типу и квалификаторам. Поддерживаются три режима: publish — рассылка всем получателям, send — отправка одному получателю с round-robin-выбором, и request-reply — запрос с типизированным ответом. Для каждого режима есть блокирующий API и реактивный API на базе Uni.

  • Гибкая модель выполнения для обработчиков сигналов. Получатели сигналов выполняются асинхронно и могут работать как блокирующие, неблокирующие или запускаемые в виртуальных потоках. Для этого используются привычные для Quarkus аннотации вроде @Blocking, @NonBlocking и @RunOnVirtualThread. Также предусмотрена регистрация и снятие обработчиков во время выполнения через fluent builder API.

  • Метаданные сигналов и SPI для интеграторов. К сигналам можно прикреплять произвольные пары ключ-значение, доступные обработчикам через SignalContext. Для расширения поведения добавлены точки интеграции SignalMetadataEnricher и ReceiverInterceptor. Расширение пока имеет экспериментальный статус, разработчики ждут обратной связи от пользователей.

  • Встраиваемые SBOM для зависимостей. Quarkus теперь умеет встраивать SBOM — Software Bill of Materials, то есть описание состава зависимостей, — прямо в собранные приложения. По умолчанию такой SBOM можно отдавать через endpoint /.well-known/sbom. Это полезно для аудита зависимостей, инвентаризации компонентов и последующего сканирования уязвимостей.

  • SBOM в нативных образах. Для native image добавлена возможность встраивать SBOM непосредственно в нативный бинарный файл согласно спецификации GraalVM SBOM. Это закрывает сценарий, когда приложение распространяется не как JVM-артефакт, а как самостоятельный исполняемый файл.

  • OIDC-аутентификация клиента через SPIFFE. В Quarkus OIDC добавлена поддержка SPIFFE JWT-токенов для аутентификации клиента перед провайдерами вроде Keycloak. Это изменение рассчитано на инфраструктуры с workload identity, zero-trust-моделью и сервис-сервисным взаимодействием, где идентичность рабочей нагрузки важнее статических секретов.

  • Произвольные типы keystore и truststore. TLS Registry теперь поддерживает произвольные типы хранилищ ключей и доверенных сертификатов, например BCFKS, через новую группу конфигурации other. Тип можно задать параметром вида quarkus.tls.key-store.other.type=<type> без написания дополнительного кода. Если для типа требуется собственная логика загрузки, можно предоставить CDI-бин KeyStoreFactory или TrustStoreFactory с соответствующим @Identifier.

  • Динамические поля в JSON-журналах. Добавлен новый SPI JsonProvider, позволяющий добавлять поля в JSON-логи динамически для каждой записи. Это даёт возможность обогащать журналы контекстом времени выполнения: например, дополнительными идентификаторами запроса, служебными метками или данными окружения.

  • Горячая перезагрузка TLS для GraphQL-клиента. GraphQL-клиент теперь поддерживает динамическую перезагрузку TLS-конфигурации. Раньше новая TLS-конфигурация подхватывалась только при создании нового экземпляра клиента, что требовало уменьшать CDI scope. Теперь обновление применяется сразу и работает в том числе для клиентов с областью application.

Дополнительные изменения и обновления компонентов

В финальном релизе 3.36.0 также отмечены доработки Signals, обновление Gradle до 9.5.1, Jackson BOM до 2.21.3, slf4j-api до 2.0.18, драйвера Microsoft SQL Server JDBC до 13.4.0, поддержка нескольких конфигураций SunPKCS11, исправление генерации POM для внешних расширений и добавление preauthorized_code как варианта OidcClient grant type.

Обновлены и компоненты платформы Quarkus: Camel Quarkus 3.36.0, Debezium 3.5.1.Final, Quarkus Amazon Services 3.19.0, Quarkus LangChain4j 1.10.0, Quarkus MCP Server 1.12.1 и Quarkus Operator SDK 7.7.5.

>>> Источник

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от dynamic_cast

Ты просто завидуешь что если перечислить все свистоперделки из этой новости с приставкой «трогал» то получается вполне законченное резюме

rukez ★★★★★
()
Ответ на: комментарий от gagarin0

«1024 файловых дескрипторов хватит на всех»

Расскажите, пожалуйста, по-подробнее. Есть ли такое ограничение на самом деле, где оно и как его увидеть по исходным текстам.

«В недрах заголовочных файлов ядра Linux жестко задано число 1024 как начальное значение и мягкого, и жесткого лимита для init-процесса. Все последующие процессы наследуют его, если userspace (systemd, PAM) не переопределит это значение.»

INR_OPEN определен в include/linux/fs.h:
#define INR_OPEN 1024		/* Initial setting for nfile rlimits */

Какая связь между дескрипторами файловыми и хендлами сокетов. «каждый сокет потребляет ровно один файловый дескриптор»

Как фреймворк решает проблему нехватки дескрипторов.

«Мультиплексирование ввода-вывода (I/O Multiplexing) Современные фреймворки используют один или несколько потоков, каждый из которых управляет тысячами соединений с помощью системных вызовов, позволяющих ядру сообщать о готовности дескриптора. epoll Процесс говорит ядру: «Я буду ждать события на любом из этих 50,000 дескрипторов». Когда на сокет приходят данные, ядро «будит» процесс и сообщает, какой именно дескриптор готов к чтению/записи.»

«Современные ядра ОС могут управлять миллионами дескрипторов, а высоконагруженные фреймворки решают проблему не их «нехватки», а эффективного управления их огромным количеством с помощью мультиплексирования (epoll/kqueue) и архитектур, не зависящих от блокирующих вызовов. Это позволяет на одном сервере держать десятки и сотни тысяч соединений.»

Saakx
()
Ответ на: комментарий от rukez

Можно, а зачем.

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

vbr ★★★★★
()
Ответ на: комментарий от doctorx

Какой контейнер. Сдурели со своими фреймворками. DI делается в одну строчку. Просто вызываешь конструктор и всё. Или сеттеры или как тебе там хочется. DI это концепция, принцип.

vbr ★★★★★
()
Ответ на: комментарий от vbr

Я на тебя посмотрю как ты будет бороться с circular reference c вызовами через конструктор. Видно больше хелловорлдов мамкины самоделкины не писали

doctorx ★★★★
()
Ответ на: комментарий от doctorx

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

vbr ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.