Les nouveautés de Java 23 : partie 3

ZGC (Z Garbage Collector) est un ramasse-miettes hautement scalable et à faible latence introduit dans la JVM Hotspot de Java 11 à titre expérimental et garanti pour une utilisation en production à partir de Java 15.

Son objectif principal est de gérer des heaps de très grande taille (jusqu’à 16 téraoctets) avec un impact minimal sur les performances des applications, en se concentrant particulièrement sur un temps de pause inférieur à la milliseconde.

Le mode générationnel pour Z Garbage Collector a été introduit dans le JDK 21 via la JEP 439. Avant cela, ZGC gérait tous les objets dans un même ensemble.

Avec le mode générationnel, ZGC gère deux générations séparées : une pour les objets jeunes et une pour les objets anciens, ce qui implique qu’elle peut récupérer les objets jeunes plus fréquemment. Ainsi, la surcharge du processeur est plus faible et la quantité de mémoire libérée est plus importante et plus rapidement.

La JEP 474 définit le mode générationnel comme utilisé par défaut pour ZGC : la valeur par défaut de l’option ZGenerational passe donc de false à true.

Le mode non générationnel, qui est généralement moins bon que le mode générationnel dans la plupart des cas, est déclaré comme déprécié dans cette version et sera supprimé dans une version future.

Avec ces modifications, le comportement suivant sera observé en fonction des arguments de ligne de commande fournis :

Cette évolution peut induire des impacts sur les applications existantes utilisant ZGC :

Un nouvel événement JFR est ajouté dans le JDK 23 : jdk.SerializationMisdeclaration.

Cet événement est émis à l’exécution lorsqu’un aspect des champs et méthodes liés à la sérialisation est mal déclaré. En activant l’événement jdk.SerializationMisdeclaration, un événement JFR sera émis pour chaque aspect incorrectement déclaré d’une classe Serializable lorsqu’elle est chargée dans la JVM.

Par exemple, si la méthode writeObject() d’une classe Serializable a une signature correcte, mais est déclarée publique par inadvertance, elle n’est pas utilisée par le mécanisme de sérialisation. Cela pourrait surprendre le développeur de la classe. Pour aider à diagnostiquer de tels problèmes, l’événement jdk.SerializationMisdeclaration peut être activé. Exemple :

Les événements jdk.SerializationMisdeclaration doivent être activés. Le profil par défaut default.jfc n’active pas ces événements, contrairement au profil profile.jfc.

Le code ci-dessus peut être compilé et exécuté avec une activation de JFR avec le profil profile enregistré dans un fichier user.jfr. Ce fichier contient un événement de type jdk.SerializationMisdeclaration

L’algorithme précédent consistait en trois passages par chaque objet actif dans le heap de la JVM :

Les emplacements des objets calculés à l’étape 2 sont stockés à l’aide de mémoire off heap pour éviter un quatrième passage pour parcourir les objets utilisés dans le heap.

Le problème est que ce schéma ne s’adapte pas bien à certaines typologies d’application. De plus, cette structure de données utilise 1,5 % du heap Java dans la mémoire off heap.

L’algorithme Full GC du ramasse-miettes Parallel GC a été réimplémenté pour utiliser un algorithme parallèle plus classique Mark-Sweep-Compact : il utilise désormais le même algorithme de full GC que celui des ramasse-miettes Serial et G1.

Le nouvel algorithme fonctionne nettement mieux pour les typologies d’applications problématiques et n’a pas besoin de mémoire supplémentaire, ce qui réduit l’empreinte mémoire. Il permet ainsi d’optimiser les performances dans certains cas spécifiques, en réduisant l’utilisation du heap de 1,5 % lors de l’utilisation de Parallel GC.

Un bug existant peut avoir empêché l’utilisation complète du heap de la JVM alloué avec l’option en ligne de commande -Xmx. Ce bug a été corrigé.

En tant qu’effet de bord de ce correctif, les JVM peuvent rencontrer une utilisation accrue du heap lors de l’utilisation de Parallel GC. Les utilisateurs doivent, si nécessaire, ajuster la taille maximale du heap.

Un nouveau mécanisme de verrouillage léger pour le verrouillage du moniteur d’objets a été introduit dans le JDK 21 (JDK-8291555).

L’option LockingMode de la JVM a été introduite pour permettre la sélection de ce nouveau mécanisme (LM_LIGHTWEIGHT, valeur 2) à la place du mécanisme par défaut (LM_LEGACY, valeur 1).

Dans le JDK 23, la valeur par défaut de LockingMode a été remplacée par LM_LIGHTWEIGHT. Cela ne devrait pas modifier le comportement sémantique du verrouillage du moniteur Java. Il devrait être neutre en termes de performances pour presque toutes les applications.

Il est possible de revenir au mécanisme historique, en utilisant l’option en ligne de commande -XX:LockingMode=1, mais il faut tenir compte que le mode historique devrait être supprimé dans une version future.

Les bases des éléments de tableau ne sont plus alignées inconditionnellement sur huit octets. Au lieu de cela, ils sont désormais alignés sur la taille de leur type d’élément. Cela améliore l’empreinte mémoire dans certains modes de la JVM. Comme l’alignement des éléments de tableau Java n’est pas exposé aux utilisateurs, il n’y a aucun impact sur le code Java standard qui accède aux éléments individuels.

Par contre, ce changement a des implications sur les méthodes d’accès de bas niveau. Les accès non sécurisés aux tableaux pourraient désormais être non-alignés. Par exemple, il n’est pas garanti que le fonctionnement de Unsafe.getLong(byteArray, BYTE_ARRAY_BASE_OFFSET + 0) soit effectué sur des plates-formes qui n’autorisent pas les accès non-alignés.

Une solution de contournement est l’utilisation des méthodes Unsafe.[get|put]Unaligned*. Les API ByteBuffer et VarHandle qui autorisent les vues de byte[] sont mises à jour pour refléter cette modification (JDK-8318966). Les tableaux obtenus via GetPrimitiveArrayCritical() ne doivent pas être exploités sous l’hypothèse d’un alignement de base de tableau particulier.

L’option TrimNativeHeapInterval permet à la JVM de réduire le heap natif à intervalles réguliers.

La syntaxe de cette option est de la forme : -XX:TrimNativeHeapInterval=millis

La valeur, précisée en ms, indique l’intervalle auquel la JVM réduira le heap natif. Des valeurs plus faibles récupéreront de la mémoire plus rapidement au prix d’une surcharge plus élevée. La valeur 0 (par défaut) désactive la réduction du heap natif. La réduction du heap natif est effectuée dans un thread dédié.

Cette option, qui était une option expérimentale, a été officiellement promue en tant qu’option produit.

Cette option n’est disponible que sur Linux avec GNU C Library (glibc).

Les annotations peuvent être traitées lors de la compilation, où javac analyse les fichiers sources à compiler à la recherche d’annotations, puis le classpath pour trouver les processeurs d’annotations correspondants, afin qu’ils puissent générer du code source.

Jusqu’au JDK 22, cette fonctionnalité était activée par défaut, ce qui était peut-être raisonnable lorsqu’elle a été introduite dans le JDK 6 vers 2006, mais d’un point de vue actuel, dans le but de rendre la sortie de construction plus robuste contre les processeurs d’annotations placés dans le classpath par inadvertance, c’est beaucoup moins raisonnable.

Jusqu’au JDK 22 inclus, le code qui nécessite un traitement des annotations avant la compilation pouvaient s’appuyer sur le comportement par défaut de javac pour traiter les annotations, mais ce n’est plus le cas.

À partir du JDK 23, l’option -proc:<policy> a été enrichie : <policy> peut maintenant avoir les valeurs suivantes :

Par conséquent, à partir du JDK 23, javac nécessite une option de ligne de commande supplémentaire pour activer le traitement des annotations. Le traitement des annotations n’est exécuté qu’avec une configuration explicite de ce traitement ou avec une demande explicite d’exécution du traitement des annotations sur la ligne de commande javac. Si ni -processor, ni --processor-path ni --processor-module-path n’est utilisé, -proc:only ou -proc:full doit être utilisé. En d’autres termes, en l’absence d’autres options de ligne de commande, -proc:none est la valeur par défaut dans le JDK 23.

Il s’agit d’un changement de comportement par rapport à la valeur par défaut existante qui consiste à chercher un traitement d’annotations en recherchant des processeurs dans le classpath sans qu’aucune option explicite liée au traitement d’annotation ne doive être présente.

Ainsi les utilisations de javac qui doivent traiter des annotations sans aucune configuration explicite de ces traitements devront être mis à jour pour continuer à exécuter les processeurs d’annotations. Dans les JDK 21 et 22, javac affiche une note identifiant ces appels.

Pour conserver l’ancien comportement, l’option -proc:full peut être passé à javac. La prise en charge de -proc:full a été rétroportée dans plusieurs mises à jour de versions LTS antérieures.

Avec Maven, il est possible d’utiliser la propriété maven.compiler.proc pour préciser le comportement : -Dmaven.compiler.proc=full dans l’option en ligne de commande.

Plusieurs mesures ont été prises pour aider les projets à se préparer au passage à -proc:full.

Un nouvel avertissement nommé dangling-doc-comments est fourni pour l’option -Xlint de javac, afin de détecter les problèmes liés au placement des commentaires de documentation dans le code source.

Cet avertissement peut être spécifié explicitement (par exemple, -Xlint:dangling-doc-comments) ou implicitement en activant toutes sous-options (par exemple, -Xlint ou -Xlint:all).

Lorsque l’avertissement est activé, javac signale tout commentaire de documentation inattendu ou mal placé à proximité d’une déclaration, comme dans les situations suivantes :

La compilation de cette classe avec tous les avertissements activés affiche deux avertissements de type dangling-doc-comments.

Comme pour toute sous-option pour -Xlint, les avertissements peuvent être supprimés localement, en utilisant l’annotation @SuppressWarnings sur une déclaration englobante, en spécifiant les noms des sous-options pour les avertissements à supprimer.

La compilation de cette classe avec tous les avertissements activés n’affiche aucun avertissement puisque les avertissements de type dangling-doc-comments ont été supprimés au niveau de la classe.

Remarque : il est possible que lorsque l’avertissement est activé, javac signale des « faux positifs » s’il y a des commentaires décoratifs commençant par /** et peuvent donc ressembler à un commentaire de documentation. Par exemple, les commentaires qui utilisent une ligne d’astérisques avant et après le reste du texte du commentaire, pour aider à faire ressortir le commentaire. La solution dans de tels cas est de changer le commentaire de sorte qu’il ne commence pas par /**, par exemple en changeant au moins un des deux astérisques en un autre caractère.

L’option --add-script de l’outil javadoc prend désormais en charge les modules JavaScript en plus des fichiers de script conventionnels. Les modules sont détectés automatiquement en inspectant l’extension ou le contenu du fichier passé en argument d’option.

La documentation de l’API générée par le doclet standard est désormais dotée de fonctionnalités de navigation améliorées, notamment une barre latérale contenant une table des matières pour la page actuelle et un fil d’Ariane pour l’élément d’API actuel dans l’en-tête de la page.

Dans la documentation des classes et des interfaces, les entrées de la table des matières peuvent être filtrées à l’aide d’un champ de saisie de texte en haut de la barre latérale.

Un bouton situé en bas de la barre latérale permet de réduire ou de développer la table des matières pour la page en cours.

La nouvelle option -verify de l’outil javap affiche des informations supplémentaires sur la vérification du bytecode de classe.

Quatre certificats racines ont été ajoutés dans le truststore cacerts :

En prévision de la suppression du Security Manager dans une version ultérieure, la méthode Subject.getSubject(AccessControlContext), dépréciée pour suppression, a été modifiée pour lever une exception de type UnsupportedOperationException si elle est appelée lorsqu’un Security Manager n’est pas permis.

Lorsque le Security Manager sera supprimé dans une version ultérieure, la méthode Subject.getSubject(AccessControlContext) sera encore modifiée pour lever une exception de type UnsupportedOperationException de manière inconditionnelle.

Pour cette version 23 du JDK, le comportement est différent selon qu’un Security Manager est autorisé ou non :

La solution de contournement temporaire dans cette version pour maintenir le code plus ancien fonctionnel consiste à utiliser l’option -Djava.security.manager=allow pour permettre la définition d’un Security Manager. La méthode Subject.getSubject() ne définit pas de Security Manager, mais exige que la fonctionnalité soit autorisée en raison du paramètre AccessControlContext.

La migration du code utilisant Subject.doAs() et Subject.getSubject() est fortement encouragée vers les API de remplacement, Subject.callAs() et Subject.current(), dès que possible. L’outil jdeprscan peut être utilisé pour analyser le classpath à la recherche d’utilisations d’API obsolètes et peut être utile pour trouver l’utilisation de ces deux méthodes.

Le code qui stocke un Subject dans un AccessControlContext et appelle AccessController.doPrivileged() avec ce contexte doit également être migré dès que possible, car ce code cessera de fonctionner lorsque le Security Manager sera supprimé.

Les mainteneurs de code qui utilise l’API Subject doivent également auditer leur code pour tous les cas où il peut dépendre de l’héritage du Subject actuel dans les threads nouvellement créés. Ce code doit être modifié pour transmettre le sujet au thread nouvellement créé ou modifié pour utiliser la concurrence structurée.

Dans les versions précédentes du JDK, RandomGeneratorFactory.create(long) utilise comme solution de fall back l’invocation de la méthode create() sans argument si l’algorithme sous-jacent ne prend pas en charge une graine (seed) longue. La méthode create(byte[]) fonctionne de la même manière.

À partir de cette version, ces méthodes lèvent désormais une exception UnsupportedOperationException plutôt que d’utiliser silencieusement create().

L’utilisation de la classe HttpsURLConnection pour se connecter à l’url https://github.com échoue avec l’utilisation du trustStore KeychainStore de MacOS :

Cela se produit parce que le KeychainStore ne contient pas les certificats d’autorité de certification intermédiaire requis et que le fournisseur d’Apple ne renvoie pas de certificats racines.

Le « KeychainStore » du fournisseur Apple prend désormais en charge deux types de keystores :

La propriété système java.security.debug accepte désormais des arguments qui ajoutent l’ID du thread, le nom du thread, les informations de l’appelant et les informations d’horodatage aux instructions de débogage pour tous les composants ou un composant spécifique.

+timestamp peut être ajouté aux options de débogage pour afficher un horodatage pour cette option de débogage

+thread peut être ajouté aux options de débogage pour afficher les informations sur le thread et l’appelant pour cette option de débogage

Exemples :

Il est possible d’utiliser l’option -Djava.security.debug=help pour afficher une liste complète des composants et arguments pris en charge.

Lors de la recherche d’une entrée keytab ou d’un cache d’informations d’identification (ccache) pour un Principal dans Kerberos, le nom du Principal est comparé au nom de l’entrée d’une manière non sensible à la casse. Toutefois, de nombreuses implémentations Kerberos traitent les noms de Principal comme sensibles à la casse. Par conséquent, si deux Principal ont des noms qui ne diffèrent que par la casse, il existe un risque de sélectionner le mauvais keytab ou l’entrée ccache.

Une nouvelle propriété de sécurité nommée jdk.security.krb5.name.case.sensitive est introduite pour contrôler la comparaison des noms. Si cette propriété vaut true, alors la comparaison des noms de Principal lors de la recherche d’entrée keytab et ccache sera sensible à la casse. La valeur par défaut est false pour garantir la compatibilité descendante.

De plus, si une propriété système portant le même nom est spécifiée, elle remplacera la valeur de la propriété de sécurité définie dans le fichier java.security.