Les nouveautés de Java 26 - partie 2

La classe java.net.SocketPermission est dépréciée pour suppression. Cette permission ne peut pas être utilisée pour contrôler l’accès aux ressources, car le Security Manager n’est plus pris en charge.

La méthode setPerformancePreferences() dans les classes java.net.Socket, java.net.SocketImpl et java.net.ServerSocket a été introduite dans Java 1.5 dans le but de fournir une API déclarative pour configurer les caractéristiques de performance du socket sous-jacent, mais son implémentation est toujours restée vide.

Ces méthodes sont dépréciées pour suppression sans aucun remplacement.

L’option -Xmaxjitcodesize sert actuellement d’alias pour -XX:ReservedCodeCacheSize, en définissant la taille du cache de code réservée en octets, c’est-à-dire la taille maximale du cache de code compilé par le JIT.

Étant obsolète depuis le JDK 1.4, elle aurait dû être dépréciée depuis ce temps. Pour simplifier la configuration de la JVM, cette option redondante est désormais marquée comme dépréciée, dans l’intention d’être supprimée dans une future version du JDK.

Exemple :

L’utilisation de -Xmaxjitcodesize doit être remplacée par -XX:ReservedCodeCacheSize.

L’option ParallelRefProcEnabled permet de contrôler si le traitement des références doit être parallélisé par les ramasse-miettes ParallelGC et G1GC.

Cette option est activée par défaut depuis de nombreuses versions et il y a peu de raison de vouloir désactiver cette fonctionnalité. Pour faciliter la maintenance, elle est dépréciée en vue d’une suppression dans une future release.

Exemple :

Le parallélisme peut toujours être contrôlé via -XX:ParallelReferencesPerThread, jusqu’à rendre cette phase à utiliser un seul thread.

Pour simplifier la taille du heap et réduire la confusion des utilisateurs, l’option MaxRAM a été marquée comme obsolète dans l’intention d’être supprimée dans une future version du JDK. Une configuration explicite de MaxRAM est rarement nécessaire, car la JVM détecte avec précision la mémoire physique disponible et les limites de validation système. Définir MaxRAM avec une valeur supérieure à la mémoire physique réelle peut entraîner une mauvaise taille du heap mais ce n’est pas un cas d’usage courant.

Exemple :

De plus, la valeur par défaut de MaxRAM a été supprimée. Dorénavant, les calculs de taille du heap sont basés sur la mémoire disponible sur le système plutôt que sur la valeur par défaut de MaxRAM, sauf si MaxRAM est explicitement définie par l’utilisateur.

Exemple avec un JDK 25 sur un laptop avec 32Go de RAM :

Exemple avec un JDK 26 sur un laptop avec 32Go de RAM :

Pour contrôler directement la taille du heap, il est préférable d’utiliser les options -Xms et -Xmx à la place.

Les options -AlwaysActAsServerClassMachine et -NeverActAsServerClassMachine sont utilisées pour influencer deux comportements :

Le mode d’émulation client était utilisé pour émuler une compilation client sur des plateformes avec un espace d’adressage virtuel réduit, principalement Windows 32 bits. Avec la dépréciation de Windows 32 bits dans le JDK 24 (JEP 479), l’intérêt à maintenir le mode d’émulation client a disparu, et donc la méthode pour influencer son activation n’est plus nécessaire.

Les deux options ont été marquées comme obsolètes dans l’intention d’être supprimées dans une future version.

Exemple :

Les utilisateurs qui comptent sur le choix d’un GC spécifique via les flags -AlwaysActAsServerClassMachine et -NeverActAsServerClassMachine doivent plutôt configurer explicitement le GC qu’ils souhaitent, par exemple en utilisant -XX:+UseSerialGC ou -XX:+UseG1GC.

Lorsque ces options seront supprimées, il ne sera plus possible d’influencer l’activation du mode d’émulation client.

L’option -AggressiveHeap a été initialement introduite pour optimiser les performances dans des scénarios de benchmarking spécifiques, mais son manque de transparence et son applicabilité limitée ont entraîné de la confusion et des résultats incohérents pour les charges de travail générales.

Pour simplifier la configuration de la JVM et encourager les utilisateurs à sélectionner explicitement les options d’ajustement qui correspondent le mieux aux besoins de l’application, cette option est désormais marquée comme dépréciée dans l’intention d’être supprimée dans une future version.

Exemple :

Pour qu’une application continue d’être exécutée avec un comportement similaire, il faut utiliser plusieurs options :

-XX:+UseParallelGC -XX:+UseLargePages -XX:-ResizeTLAB -XX:TLABSize=256K -XX:YoungPLABSize=256K -XX:OldPLABSize=8K -XX:ThresholdTolerance=100

Et configurer plusieurs valeurs relatives au heap :

Les applets ont en leur temps contribué au succès initial de Java, en permettant de dynamiser les pages web avant l’utilisation de JavaScript.

Les applets sont devenues inutilisables depuis que tous les navigateurs modernes ont abandonné le support du connecteur permettant d’exécution de plugins et que le JDK ne propose plus aucun moyen de les exécuter.

Ainsi, l’API Applet a suivi un long cycle de dépréciation :

Tous les éléments relatifs aux applets sont retirés définitivement du JDK 26 en supprimant l’API Applet et les classes Java liées aux applets, ainsi que les méthodes faisant référence à l’API Applet :

Leur suppression dans le JDK 26 tourne une page de l’histoire du web et de Java.

Plusieurs fonctionnalités qui ne font pas l’objet d’une JEP sont retirées.

Le support de la finalisation des objets sera retiré dans une future version du JDK. En prévision de cela, l’utilisation de ce mécanisme a été retirée de la classe javax.imageio.stream.ImageInputStreamImpl et de toutes ses sous-classes.

La méthode stop() de la classe java.lang.Thread, intrinsèquement dangereuse, a été dépréciée dans le JDK 1.2 (décembre 1998, soit plus de 27 ans) car elle pouvait entraîner des états incohérents et des comportements imprévisibles. Dans le JDK 18, elle a été marquée comme dépréciée pour suppression, et depuis le JDK 20, elle a été respécifiée pour lever systématiquement une exception de type UnsupportedOperationException.

Dans le JDK 26, cette méthode est supprimée et le code l’utilisant ne compilera plus. Le code utilisant cette méthode et compilé dans les versions antérieures lèvera une NoSuchMethodError au lieu d’une UnsupportedOperationException s’il est exécuté sur un JDK 26 ou plus récent.

Plusieurs méthodes, dépréciées pour suppression, ont été supprimées.

Dans la classe java.net.MulticastSocket :

Dans la classe java.net.DatagramSocketImpl :

Le support intégré dans le JDK du protocole InfiniBand Sockets Direct (SDP) sous Linux a été supprimé.

Le SDP est obsolète depuis de nombreuses années et n’est plus soutenu par aucune distribution grand public.

La propriété système com.sun.sdp.conf qui pouvait être utilisée pour configurer l’utilisation du SDP dans le fichier fourni comme valeur, ainsi que le fichier de configuration d’exemple $JAVA_HOME/conf/sdp/sdp.conf.template, sont également supprimés.

La normalisation des noms de fichiers n’est pas effectuée par APFS, qui a succédé à HFS+ en tant que système de fichiers sous macOS en septembre 2017.

Pour permettre la rétrocompatibilité, la propriété système jdk.nio.path.useNormalizationFormD de la JVM, ajoutée dans le JDK 20, précise la façon dont les chemins de fichiers sont normalisés au niveau Unicode (forme composée (NFC) sur un seul caractère ou forme décomposée (NFD) : caractère de base + accent) dans l’API NIO (java.nio.file).

Étant donné qu’aucune version actuellement prise en charge de macOS n’effectue la normalisation des chemins de fichiers, le support de cette propriété a été supprimé.

Le support des fonctionnalités d’échange XML dans la classe javax.management.modelmbean.DescriptorSupport est retiré : cela concerne le constructeur DescriptorSupport(String) et la méthode toXMLString() qui sont supprimés.

De plus, la classe javax.management.modelmbean.XMLParseException est supprimée.

Le module jdk.jsobject a été retiré du JDK : il est inclus avec JavaFX 24 et versions ultérieures.

L’outil expérimental et non supporté jrunscript a été retiré du JDK.

Le but de la JEP 516 est d’étendre les capacités du cache Ahead-of-Time (AOT), introduit par le Projet Leyden, pour permettre son utilisation avec tous les ramasse-miettes, y compris ZGC.

Jusqu’au JDK 25, le cache AOT stockait les objets dans un format dépendant du GC, ce qui empêchait la compatibilité avec ZGC ou avec des configurations mémoire particulières (taille du heap, Compressed OOPs, Compact Object Headers,…​).

Le cache AOT contenait des instances d’objets (notamment Class, chaînes, tableaux), mais dans un format binaire propre au GC utilisé pendant l’exécution de la phase d’entraînement. Cette approche permettait de mapper directement le fichier du cache dans la mémoire, offrant de grandes performances si le fichier était dans le cache du système de fichiers. Cependant, cela imposait plusieurs grosses contraintes :

Cela rendait impossible de combiner démarrage rapide avec la faible latence de ZGC.

Dans le JDK 26, les objets peuvent être stockés dans un format neutre, où les références internes sont remplacées par des indices logiques. Au démarrage de l’exécution, un thread en arrière-plan lit le cache et recrée les objets dans le heap selon le GC utilisé.

Cette fonctionnalité est un compromis :

La JVM propose désormais deux versions du cache AOT :

Le choix se fait :

Le format streamable est utilisé par défaut si ZGC est utilisé, le heap > 32 Go et les compressed OOPs sont désactivés.

JEP 522 introduit une optimisation au ramasse-miettes G1, dont l’objectif est d’augmenter le débit des applications Java en réduisant la surcharge induite par la synchronisation entre les threads applicatifs et les threads du GC. Cette amélioration cible l’un des points du fonctionnement interne de G1 : la gestion de la card table et des barrières d’écriture (write barriers).

G1 est un ramasse-miettes régional : le heap est divisé en régions, et les références entre les régions sont suivies via une structure dédiée appelée card table.
Lorsque le code met à jour une référence d’objet, une barrière d’écriture marque la card correspondante comme « sale » (dirty).

Avant le JDK 26, les threads de l’application et du GC modifiaient la même card table. Pour éviter des corruptions, G1 devait synchroniser chaque accès lors des mises à jour. Ces verrouillages pouvaient provoquer de la contention, particulièrement dans les applications qui modifient intensément des références. Ce mécanisme dégradait le débit, et expliquait pourquoi G1 pouvait être moins performant que ParallelGC dans certains cas avec fortes charges concurrentielles.

Le JDK 26 introduit une deuxième card table afin d’éliminer la synchronisation entre le GC et les threads de l’application. Les threads applicatifs écrivent dans une card table dédiée, sans aucun verrou. Un thread du GC optimise ou scanne l’autre card table en parallèle. Lorsque la table utilisée par l’application devient trop chargée, le GC échange les deux card tables atomiquement. Le processus continue sans jamais nécessiter de synchronisation entre application et GC. Ce mécanisme permet également de simplifier le code de la barrière d’écriture.

Les gains envisageables sont de 5 à 15 % de débit supplémentaire pour les applications qui modifient fréquemment des références avec environ 5 % d’amélioration générale même pour des workloads plus classiques.

Sur x64, le code de la barrière d’écriture passe d’environ 50 instructions à 12, diminuant directement le coût des écritures. Le surcoût mémoire est minime : environ 0,2 % du heap soit environ 2 Mo par Go de heap.

D’autres fonctionnalités ou évolutions dans des fonctionnalités de la JVM HotSpot ne faisant pas l’objet d’une JEP sont proposées dans le JDK 26.

À la fin de l’exécution de la VM, l’option -Xlog:cpu affiche désormais un tableau décomposant l’utilisation de la CPU par les composants de la JVM.

Exemple :

L’exécution d’un programme sources avec un constructeur privé sans argument provoque une erreur, comme le fait l’exécution de l’application en mode classe.

Exemple :

Exemple : exécution avec un JDK 25

Exemple : exécution avec un JDK 26

Le ramasse-miettes G1 peut désormais lever une OutOfMemoryError lorsque le surcoût du GC dépasse le GCTimeLimit (98 % par défaut) et que la mémoire libre tombe sous la GCHeapFreeLimit (2 % par défaut) durant cinq cycles consécutifs.

Ce comportement est activé par défaut, mais peut être désactivé avec l’option -XX:-UseGCOverheadLimit

L’implémentation est alignée sur celle du ramasse-miettes ParallelGC bien que leurs conditions exactes de lever de l’OutOfMemoryError puissent légèrement varier.

Le ramasse-miettes G1 récupère désormais plus rapidement les « humongous objects » éligibles (grands objets ou tableaux occupant plus de la moitié d’une région du heap qui ne sont plus référencés), même ceux contenant des références, sans attendre un marquage complet de l’ensemble du heap.

Cela permet de libérer plus rapidement la mémoire des objets non référencés et d’améliorer l’efficacité du GC, en particulier pour les objets volumineux et de courte durée de vie.

Dans certaines circonstances, les threads virtuels sont « épinglés » à leur thread porteur, ce qui signifie que si le thread virtuel est bloqué, il ne peut pas être détaché de son thread porteur qui est le thread du système d’exploitation sur lequel le thread virtuel est exécuté. Ainsi, le thread porteur est également bloqué et ne peut pas exécuter un autre thread virtuel.

Dans le JDK 24, la principale raison d’épinglage de threads virtuels sur leur thread porteur a été résolu (exécution de code synchronized).

Dans le JDK 26, un thread virtuel qui tente d’initialiser une classe déjà en cours d’initialisation par un autre thread sera désormais, dans la plupart des cas, détaché de son thread porteur en attendant. Auparavant, le comportement consistait à épingler le thread virtuel sur son thread porteur en attendant que l’autre thread exécute l’initialiseur de la classe.

Ce changement peut améliorer les performances dans certains cas, car le détachement libère le thread porteur (thread de plateforme), permettant au planificateur de thread virtuel d’exécuter un autre thread virtuel.

Ce changement aide également à résoudre le cas où tous les threads de plateforme disponibles pour le planificateur de threads virtuels du JDK sont épinglés par des threads virtuels en attendant qu’un autre thread exécute un initialiseur de classe. Si le thread exécutant l’initialiseur de classe bloque ou attend quelque chose nécessitant un thread virtuel pour être exécuté, le système pourrait devenir bloqué, car aucun thread virtuel ne pourrait continuer son exécution.

Avant le JDK 26, un thread virtuel était également épinglé s’il tentait d’initialiser une classe en cours d’initialisation par un autre thread. Cela n’arrive plus non plus.

Le compilateur JIT C2 peut désormais compiler des méthodes avec un grand nombre de paramètres. Auparavant, C2 tentait de compiler de telles méthodes, mais revenait au code compilé en C1 ou à l’interpréteur.

Ce changement permet aux applications de bénéficier des optimisations du JIT C2 pour un plus large éventail de méthodes, améliorant ainsi les performances.

Le ramasse-miettes G1 peut à nouveau utiliser correctement les Transparent Huge Pages (THP) sur des systèmes avec le mode THP configuré comme madvise. Le problème empêchant l’option -XX:+UseTransparentHugePages d’activer le THP a été résolu.

Si la taille initiale du heap de la JVM n’est pas précisée à l’aide de -Xms ou -XX:InitialHeapSize, la JVM détermine la taille initiale du heap en utilisant le paramètre InitialRAMPercentage. Par défaut, c’est 1/64 de la RAM physique du système.

Exemple avec le JDK25

Ce comportement entraîne de grandes tailles initiales de heap sur les systèmes modernes disposant d’une quantité importante de mémoire, augmentant les temps de démarrage de la JVM en raison de l’initialisation nécessaire des structures de données internes liées au heap.

Dans le JDK 26, la valeur par défaut de la propriété InitialRAMPercentage est supprimée. Maintenant, si l’utilisateur ne spécifie pas de taille initiale du heap Java, la JVM fixe la taille initiale du heap à la taille minimale possible, qui correspond à MinHeapSize. Cela améliore les performances au démarrage des configurations JVM par défaut en réduisant l’initialisation de la mémoire interne.

Exemple avec le JDK 26

Pour obtenir le comportement précédent, il est possible de définir explicitement la valeur de la propriété InitialRAMPercentage à la valeur originale de 1,5625, ou configurer directement la taille initiale du heap Java en utilisant les options -Xms ou -XX:InitialHeapSize.

Si ni -Xms ni -XX:InitialRAMPercentage ne sont utilisés pour spécifier une taille minimale du heap lors du lancement de la JVM, le heap est défini par défaut à 1/64 (= 1,5625 %) de la RAM physique. Aujourd’hui, les ordinateurs disposent de beaucoup plus de RAM, donc de nombreuses applications sont démarrées avec un heap inutilement grand.

Exemple avec le JDK 25 sur un laptop avec 32Go de RAM

En plus de la RAM inutilement occupée, cela peut aussi retarder notablement le démarrage d’une application, car le ramasse-miettes doit créer des structures de données initiales pour le heap, qui évoluent avec la taille du heap.

Dans le JDK 26, la taille initiale du heap par défaut est modifiée à 0,2%, c’est-à-dire 1/500 de la RAM physique.

Exemple avec le JDK 26 sur un laptop avec 32Go de RAM

La taille de l’Eden et des espaces Survivor à l’intérieur d’une jeune génération est régie par SurvivorRatio. Ces tailles peuvent changer lorsque la taille de la jeune génération est mise à jour.

Après ce changement, si heap est presque plein, Serial GC essaiera d’étendre l’Eden afin de satisfaire la demande d’allocation. Cela peut faire croître la taille de l’Eden au-delà de la limite définie par SurvivorRatio.

Ce nouveau comportement peut éviter les erreurs de type OutOfMemoryError dans des situations de heap très restreintes qui auparavant terminaient souvent la JVM.

La documentation générée par l’outil javadoc propose désormais un thème sombre.

Le thème clair est toujours celui par défaut, mais le nouveau thème sombre peut être sélectionné via le bouton nouveau thème dans la barre de navigation.

Il est possible de sélectionner le thème sombre (dark).

Les thread dumps produits par la méthode HotSpotDiagnosticMXBean::dumpThreads ou la commande jcmd <pid> Thread.dump_to_file incluent désormais l’information sur le détenteur du "park blocker" pour les threads bloqués sur un objet de java.util.concurrent.locks.AbstractOwnableSynchronizer, facilitant ainsi le diagnostic des blocages.

Exemple :

Avant le JDK 26, le compilateur javac n’appliquait pas de conversion de capture imposée par la JLS lors de la décision de la compatibilité d’une référence de méthode avec un type de fonction donné. Cela pouvait amener le compilateur javac à compiler sans erreur le code ci-dessous :

Exemple :

Résultat de la compilation avec un JDK 25 :

À partir du JDK 26, le compilateur javac appliquera la conversion de capture obligatoire par la JLS lorsqu’il décide si une référence de méthode est compatible avec un type de fonction donné.

Résultat de la compilation avec un JDK 26 :

L’outil jlink peut être utilisé pour assembler un ensemble de modules et leurs dépendances en un runtime d’exécution personnalisée pour un système d’exploitation, une architecture ou une version du JDK différente de celle contenant l’outil jlink. Cette fonctionnalité est appelée « cross linking ».

Dans les versions précédentes, la vérification de la version était moins stricte et permettait à jlink exécuté d’un JDK $N.0.$U du fournisseur $X de créer une image d’exécution à partir d’un ensemble de modules pour un JDK $N.0.$V d’un fournisseur $Y.

La vérification des versions utilisée lors du cross linking est devenue plus stricte que dans les versions précédentes. La vérification stricte signifie que la valeur de $U et $V doit être égale, et que $X et $Y être égales. Lors du cross linking, l’ensemble des modules standard et le JDK pour l’exécution personnalisée doit correspondre exactement à la version et au fournisseur du JDK contenant l’outil jlink. Cette vérification stricte est nécessaire en raison du pipeline de plugins jlink qui transforment et optimisent les classes et ressources intégrées à l’image. L’outil jlink ne peut pas générer de manière fiable une image à l’exécution lorsqu’elles ne correspondent pas exactement.

Le JDK 26 propose diverses évolutions dans JFR.

Les événements JFR jdk.ModuleExport, jdk.SymbolTableStatistics et jdk.StringTableStatistics ont été désactivés dans la configuration JFR par défaut (default.jfc) afin de réduire la charge lorsque JFR n’est pas explicitement configuré.

Il est possible d’activer ces événements dans le paramètre d’événement, par exemple en demandant le démarrage de JFR dans les options de la JVM : -XX:StartFlightRecording:jdk.ModuleExport#enabled=true

Deux nouveaux événements JFR sont ajoutés, tous les deux activés par défaut dans les configurations default et profile :

Exemple :

Le but est d’introduire une API facile à utiliser pour l’encodage d’objets qui représentent des clés cryptographiques, des certificats et des listes de révocation de certificats dans le format de transport PEM (Privacy-Enhanced Mail) largement utilisé, et pour le décodage de ce format en objets.

Les formats standards utilisés sont :

PEM est un format textuel pour les données binaires. Un texte PEM contient une représentation en Base64 de la représentation binaire d’objet cryptographique, entourée d’un en-tête contenant -----BEGIN PUBLIC xxx----- et d’un pied contenant -----END PUBLIC xxx----- ou xxx est le type de l’objet.

L’API PEM a été proposée comme une fonctionnalité en preview par la JEP 470 et livrée dans le JDK 25. Elle est de nouveau proposée en preview par la JEP 524 avec plusieurs modifications dans son API :

Le JDK 26 propose aussi plusieurs autres évolutions relatives la sécurité :

La commande keytool lit les mots de passe depuis la console système pour empêcher qu’ils ne s’affichent à l’écran. Cependant, la console n’est généralement disponible que lorsque les flux d’entrée et de sortie standards ne sont pas redirigés.

Auparavant, si le flux de sortie standard était redirigé vers un fichier ou une autre commande, la console était indisponible et le mot de passe d’entrée était affiché à l’écran.

Cette évolution améliore la gestion des mots de passe afin de garantir que le mot de passe ne soit pas affiché à l’écran même si le flux de sortie standard est redirigé. Cette amélioration a également été apportée à la commande jarsigner et à l’API JAAS com.sun.security.auth.callback.TextCallbackHandler.

Le JDK supporte désormais la création et la vérification de fichiers JAR signés avec l’algorithme post-quantique ML-DSA, en utilisant PKCS #7 tel que défini dans la RFC 9882. Cette fonctionnalité est disponible via l’outil jarsigner et l’API JarSigner.

Exemple

La nouvelle propriété de sécurité nommée jdk.crypto.disabledAlgorithms a été introduite pour désactiver les algorithmes des services cryptographiques JCE/JCA. Initialement, cette propriété ne prend en charge que les services Cipher, KeyStore, MessageDigest et Signature.

Cette propriété est définie dans le fichier conf/security/java.security du JDK et initialement aucun algorithme n’est désactivé par défaut.

Cependant, cela pourrait changer dans les prochaines versions du JDK. Cette propriété de sécurité peut être écrasée par une propriété système du même nom si les applications doivent réactiver des algorithmes désactivées par défaut.

L’algorithme de chiffrement HPKE, défini dans la RFC 9180: Hybrid Public Key Encryption est un chiffrement à clé publique permettant de chiffrer du texte de taille arbitraire avec la clé publique d’un destinataire.

HPKE combine un mécanisme d’encapsulation de clés (KEM), une fonction de dérivation de clés (KDF) et un chiffrement authentifié avec un chiffrement de données supplémentaires (AEAD). Tous les identifiants d’algorithmes KEM, KDF et AEAD définis dans la RFC 9180 sont pris en charge.

La nouvelle classe HPKEParameterSpec permet de choisir des identifiants d’algorithme et de définir d’autres paramètres tels que les modes HPKE, les informations fournies par l’application et les clés spécifiques au mode.

Exemple :

Résultat d’exécution

La KeyManagerFactory par défaut « SunX509 » pour TLS prend désormais en charge les mêmes contraintes d’algorithmes et la même fonctionnalité de vérification des certificats que la KeyManagerFactory « PKIX ». La sélection et la priorisation des certificats locaux choisis par le KeyManager se basent sur les contrôles suivants :

Le comportement précédent du gestionnaire de clés « SunX509 », sans vérification des certificats locaux, peut être restauré en mettant la propriété système jdk.tls.SunX509KeyManager.certChecking à false.

Une nouvelle propriété appelée jdk.xmldsig.SecureRandom a été ajoutée pour la classe javax.xml.crypto.dom.DOMCryptoContext afin de pouvoir utiliser sa propre instance de type java.security.SecureRandom.

Il faut invoquer la méthode setProperty() sur l’instance de type SignContext avec en paramètres "jdk.xmldsig.SecureRandom" et l’instance de SecureRandom avant d’invoquer la méthode XMLSignature.sign().

Exemple :

Résultat

Plusieurs certificats racines AffirmTrust, qui sont désactivés et ne sont plus utilisés plus, ont été retirés du keystore cacerts :

Lors de la configuration de nouvelles connexions, java.net.http.HttpClient utilise dorénavant les schémas de signature et les groupes nommés configurés dans SSLParameters lors de la négociation du handshake TLS. Auparavant, ces valeurs configurées étaient ignorées.

L’implémentation PKCS12 du KeyStore dans le JDK prend désormais en charge l’algorithme PBMAC1 plus moderne pour la protection de l’intégrité. Pour utiliser l’algorithme PBMAC1, il faut définir la propriété keystore.pkcs12.macAlgorithm dans le fichier de configuration java.security avec un algorithme PBMAC1. Par exemple, « PBEWithHmacSHA256 ».

Les fichiers keystore existants utilisant PKCS12 continueront d’utiliser l’algorithme d’intégrité avec lequel ils ont été créés, mais les nouveaux fichiers keystore utiliseront l’algorithme PBMAC1.

Dans une future version du JDK, la valeur par défaut de la propriété de sécurité keystore.pkcs12.macAlgorithm sera changée en un algorithme PBMAC1.

Le JDK cessera de faire confiance aux certificats serveur TLS émis après le 17 mars 2026 incluant des certificats racines Chunghwa, conformément à des plans similaires annoncés par Google et Mozilla.

Les certificats serveur TLS émis au plus tard le 17 mars 2026 continueront d’être fiables jusqu’à leur expiration. Les certificats délivrés après cette date, et incluant l’autorité de certification ci-dessous, seront rejetés :

Distinguished Name : OU=ePKI Root Certification Authority, O="Chunghwa Telecom Co., Ltd.", C=TW

Empreinte SHA-256 : C0:A6:F4:DC:63:A2:4B:FD:CF:54:EF:2A:6A:08:2A:0A:72:DE:35:80:3E:2F:F5:FF:52:7A:E5:D8:72:06:DF:D5

Les restrictions sont appliquées dans l’implémentation du JDK (le fournisseur SunJSSE) de l’API Java Secure Socket Extension (JSSE). Une session TLS ne sera pas négociée si la chaîne de certificats du serveur d’une des autorités de certification et le certificat a été émis après le 17 mars 2026. Dans ce cas, le message d’erreur ci-dessous sera affiché :

"TLS Server certificate issued after 2026-03-17 and anchored by a distrusted legacy Chunghwa root CA: OU=ePKI Root Certification Authority, O="Chunghwa Telecom Co., Ltd." C=TW"

Le JDK peut être configuré pour faire à nouveau confiance à ces certificats en supprimant « CHUNGHWA_TLS » de la propriété de sécurité jdk.security.caDistrustPolicies dans le fichier de configuration java.security.

Les outils et les API KeyStore ont été mis à jour pour avertir les utilisateurs lorsque des KeyStore JKS et JCEKS obsolètes sont utilisés, car ils utilisent des algorithmes cryptographiques obsolètes et seront supprimés dans une future version. Il est conseillé de migrer vers un Keystore PKCS12 en utilisant la commande keytool -importkeystore.

Les changements suivants ont été apportés :

Tous les avertissements informent l’utilisateur que JKS et JCEKS utilisent des algorithmes cryptographiques obsolètes et seront supprimés lors d’une future release. Il est conseillé aux utilisateurs de migrer vers un keystore PKCS12.

Exemple :

Cette fonctionnalité fournit de nouvelles fonctions intrinsics utilisant les instructions AVX2 sur les plateformes x86_64 pour l’algorithme de signature ML-DSA du fournisseur de sécurité SUN.

Elle améliore également les fonctions intrinsics AVX512 existantes pour l’algorithme ML-DSA. Cette optimisation est activée par défaut sur les plateformes x86_64 compatibles. Elle peut être désactivée en utilisant les options de ligne de commande -XX:+UnlockDiagnosticVMOptions et -XX:-UseDilithiumIntrinsics.

L’option -XshowSettings:security:tls de la JVM a été mise à jour pour afficher la liste des groupes nommés activés et celle des schémas de signature activés utilisés pour les procédures d’établissement de connexion (handshakes) SSL/TLS/DTLS.

Exemple :

Les signatures XML utilisant des transformations XPath ont été désactivées par défaut. La transformation XPath n’est pas recommandée par le document XML Signature Best Practices. Les applications devraient utiliser la transformation XPath Filter 2.0 à la place, qui a été conçue comme une alternative à la transformation XPath.

Si nécessaire, et à leurs risques et périls, les applications peuvent contourner cette politique en modifiant la propriété de sécurité jdk.xml.dsig.secureValidationPolicy pour ne plus interdire la transformation XPath 1.0 dans le fichier java.security du JDK.

Différents algorithmes de sécurité ont été supprimés dans la spécification Java Security Standard Algorithm Names et les spécifications des API, car ils ne sont plus recommandés et ne devraient plus être utilisés :

Plusieurs algorithmes PBES2 définis dans la RFC 8018: PKCS #5: Password-Based Cryptography Specification Version 2.1 ont été ajoutés dans les spécifications :