Publication de la version Quarkus 3.36 — Framework Java pour les applications cloud-native, axé sur les conteneurs, Kubernetes, JVM et la compilation native. La sortie a eu lieu le 27 mai 2026. Les principales modifications concernent un nouveau mécanisme expérimental d'échange de signaux entre composants, des améliorations en matière de sécurité de la chaîne d'approvisionnement, de TLS et d'authentification OIDC pour des scénarios zero-trust.
Pour la mise à jour, les développeurs recommandent d'utiliser la version récente de Quarkus CLI et d'exécuter :
quarkus update
La commande quarkus update, selon le projet, peut mettre à jour les applications vers Quarkus 3.36 même à partir des branches Quarkus 2.x.
Principales modifications
Quarkus Signals — extension expérimentale pour l'échange de signaux entre composants.
Quarkus a introduit un nouveau mécanisme qui permet aux composants de l'application d'interagir de manière faiblement couplée : un composant envoie un signal, l'autre le reçoit. La résolution des destinataires est typiquement sécurisée et inspirée des événements CDI : les signaux sont associés aux gestionnaires par type et qualificatifs. Trois modes sont pris en charge : publish — diffusion à tous les destinataires, send — envoi à un destinataire unique avec sélection round-robin, et request-reply — demande avec réponse typée. Pour chaque mode, il existe une API bloquante et une API réactive basée sur Uni.Modèle d'exécution flexible pour les gestionnaires de signaux.
Les destinataires des signaux s'exécutent de manière asynchrone et peuvent fonctionner comme bloquants, non bloquants ou lancés dans des fils virtuels. Pour cela, des annotations familières à Quarkus telles que @Blocking, @NonBlocking et @RunOnVirtualThread sont utilisées. L'enregistrement et la suppression des gestionnaires à l'exécution via l'API de constructeur fluide sont également prévus.Métadonnées de signaux et SPI pour les intégrateurs.
Des paires clé-valeur arbitraires peuvent être attachées aux signaux, accessibles aux gestionnaires via SignalContext. Pour étendre le comportement, des points d'intégration SignalMetadataEnricher et ReceiverInterceptor ont été ajoutés. L'extension a encore un statut expérimental et les développeurs attendent des retours d'expérience des utilisateurs.SBOM intégrés pour les dépendances.
Quarkus peut désormais intégrer des SBOM — Software Bill of Materials, c'est-à-dire une description de la composition des dépendances — directement dans les applications construites. Par défaut, un SBOM peut être fourni via l'endpoint /.well-known/sbom. C'est utile pour l'audit des dépendances, l'inventaire des composants et la scan des vulnérabilités par la suite.SBOM dans les images natives.
Une fonctionnalité a été ajoutée pour intégrer le SBOM directement dans le fichier binaire natif selon la spécification GraalVM SBOM. Cela couvre le scénario où l'application est distribuée non pas comme un artefact JVM, mais comme un exécutable autonome.Authentification OIDC du client via SPIFFE.
Quarkus OIDC prend désormais en charge les jetons JWT SPIFFE pour l'authentification des clients auprès de fournisseurs comme Keycloak. Ce changement est destiné aux infrastructures avec identité de charge de travail, un modèle de zero-trust et une interaction service à service, où l'identité de la charge de travail est plus importante que les secrets statiques.Types de keystore et truststore arbitraires.
Le registre TLS prend désormais en charge des types arbitraires de magasins de clés et de certificats de confiance, comme BCFKS, via un nouveau groupe de configuration 'other'. Le type peut être défini par le paramètre quarkus.tls.key-store.other.type= sans écrire de code supplémentaire. Si une logique de chargement spécifique est requise pour le type, vous pouvez fournir un CDI bean KeyStoreFactory ou TrustStoreFactory avec le bon @Identifier.Champs dynamiques dans les journaux JSON.
Un nouveau SPI JsonProvider a été ajouté, permettant d'ajouter des champs aux journaux JSON de manière dynamique pour chaque enregistrement. Cela permet d'enrichir les journaux avec le contexte d'exécution : par exemple, des identifiants de requêtes supplémentaires, des balises de service ou des données d'environnement.Recharge à chaud du TLS pour le client GraphQL.
Le client GraphQL prend désormais en charge le rechargement dynamique de la configuration TLS. Auparavant, une nouvelle configuration TLS n'était appliquée qu'à la création d'une nouvelle instance du client, ce qui nécessitait de réduire la portée CDI. Désormais, la mise à jour s'applique immédiatement et fonctionne également pour les clients ayant une portée d'application.
Modifications et mises à jour supplémentaires des composants
Dans la version finale 3.36.0 , des améliorations des Signals ont également été notées, mise à jour de Gradle vers 9.5.1, Jackson BOM vers 2.21.3, slf4j-api vers 2.0.18, driver Microsoft SQL Server JDBC vers 13.4.0, prise en charge de plusieurs configurations SunPKCS11, correction de la génération POM pour les extensions externes et ajout du preauthorized_code comme option de type de grant pour OidcClient.
Les composants de la plateforme Quarkus ont également été mis à jour : 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 et Quarkus Operator SDK 7.7.5.
Source : linux.org.ru
