Les nouveautés de Java 25 - partie 2

Sous Linux, l’option -Djdk.lang.Process.launchMechanism=VFORK a été dépréciée car, elle était intrinsèquement dangereuse.

Elle sera supprimée dans une prochaine version.

Il est conseillé d’éviter d’utiliser cette propriété. Si possible, il faut la supprimer et utiliser le mécanisme de lancement par défaut basé sur posix_spawn.

Au cas où ce n’est pas possible, il faudrait utiliser -Djdk.lang.Process.launchMechanism=FORK à la place.

La propriété système java.locale.useOldISOCodes est dépréciée. Elle a été introduite dans le JDK 17 pour permettre de revenir aux codes de langue ISO 639 hérités pour l’hébreu, l’indonésien et le yiddish le temps de mettre à jour le code.

Dans le JDK 25, elle est dépréciée : la définition de cette propriété sur true n’a aucun effet, et un avertissement concernant sa suppression future s’affiche au moment de l’exécution.

La classe javax.management.modelmbean.DescriptorSupport de l’API JMX représente les métadonnées de MBean. Elle dispose d’un constructeur et d’une méthode permettant de créer et d’exporter vers XML.

Ceux-ci ne sont pas utilisés dans le JDK et n’ont pas d’utilisation plus large connue : elles sont dépréciées pour suppression.

La classe javax.management.modelmbean.XMLParseException, qui n’est levée que par la classe DescriptorSupport, est également dépréciée pour suppression.

L’option UseCompressedClassPointers était utilisée pour basculer entre deux modes :

Le mode de pointeur de classe non compressé entraîne l’utilisation de plus de mémoire par la JVM. Il sert à très peu de choses aujourd’hui. Il sera supprimé dans une future version de Java. Étant donné que cela ne laisse que le mode de pointeur de classe compressé par défaut, l’option sera également supprimée.

Le mode de pointeur de classe compressé par défaut permet à la JVM de placer des classes dans l’espace de classes qui est limité par défaut à 1 Go.

Dans les rares cas où une application doit charger plus que cela, l’espace de classe peut être étendu jusqu’à 4 Go avec l’option -XX:CompressedClassSpaceSize.

L’option UseCompressedClassPointers est dépréciée dans le JDK 25 et sera supprimée dans une future version de Java :

Si l’application épuise l’espace de classe, il faut investiguer les causes si cette situation est pathologique (fuite de class loader) ou sinon il faut augmenter l’espace de classe en utilisant l’option -XX:CompressedClassSpaceSize.

Dans le JDK 25, différentes classes d’autorisation ont été dépréciées pour suppression :

De plus, la méthode getPermission() définie dans la classe java.net.URLConnection et sa sous-classe java.net.HttpURLConnection ont été dépréciées pour suppression.

Ces classes d’autorisation et les méthodes associées n’étaient utiles qu’en conjonction avec le Security Manager, qui n’est plus pris en charge.

Le but de la JEP 503 est de supprimer le code source et le build du portage x86 32 bits.

Ce portage a été déprécié pour suppression dans le JDK 24 (JEP 501) avec l’intention de le supprimer dans une version ultérieure.

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

La fonctionnalité d’échantillonnage périodique PerfData a été supprimée, y compris le StatSampler et son flag de contrôle -XX:PerfDataSamplingInterval.

L’échantillonnage PerfData était un mécanisme rarement utilisé qui mettait régulièrement à jour un petit ensemble de compteurs dans le fichier PerfData. Pour la plupart des ramasse-miettes, comme pour G1 et ZGC, il n’enregistrait qu’un horodatage.

Avec ce changement :

Cette modification ne concerne que les outils qui lisent les données directement à partir du fichier PerfData. Les autres programmes et outils de surveillance ne sont pas impactés.

Les anciens compteurs de performances du moniteur d’objets, exposés dans l’espace de noms sun.rt._sync* sont supprimés. Ces compteurs étaient rarement utilisés et ils contribuaient à des problèmes de performances dans le code VM associé. Il est conseillé aux utilisateurs qui souhaitent suivre les performances du moniteur d’utiliser à la place des événements JFR associés.

Les remplacements suggérés sont les suivants :

Certaines anciennes propriétés système de JMX permettant d’aider à la compatibilité durant une période de transition sont supprimées :

JDK Flight Recorder (JFR) peut déjà profiler la consommation de deux ressources d’un programme :

Le but de la JEP 509 est d’améliorer le JFR pour capturer les informations de profilage du temps CPU sous Linux uniquement. Il s’agit d’une fonctionnalité expérimentale.

La capacité de mesurer avec précision la consommation des cycles CPU a été ajoutée au noyau Linux dans la version 2.6.12 via un timer qui émet des signaux à des intervalles fixes de temps CPU plutôt qu’à des intervalles fixes de temps réel écoulé. La plupart des profilers sous Linux utilisent ce mécanisme pour produire des profilages du temps CPU.

JFR utilise le mécanisme CPU-timer de Linux pour échantillonner la pile de chaque thread exécutant du code Java à des intervalles fixes de temps CPU. Chacun de ces échantillons est enregistré dans un nouveau type d’événement, jdk.CPUTimeSample. Cet événement n’est pas activé par défaut.

Un rendu textuel des méthodes chaudes en CPU, c’est-à-dire celles qui consomment de nombreux cycles CPU dans leur propre corps plutôt que dans les appels à d’autres méthodes, peut être obtenu comme suit :

Le taux d’échantillonnage de cet événement peut être défini via la propriété throttle de l’événement.

Autre nouvel événement, jdk.CPUTimeSampleLoss est émis lorsque des échantillons sont perdus en raison de contraintes d’implémentation.

Les caches ahead-of-time, introduits via la JEP 483 dans le JDK 24, permettent d’accélérer le démarrage des applications Java.

Dans le JDK 24, la création d’un cache AOT se faisait en deux étapes, en utilisant la commande java dans deux modes AOT distincts :

Le but de la JEP 514 est de faciliter la création de caches ahead-of-time en simplifiant les commandes requises pour les cas d’utilisation courants.

Une nouvelle option de la commande java, AOTCacheOutput, permet de spécifier un fichier de sortie de cache AOT. Lorsqu’elle est utilisée seule, sans autres options AOT*, cette option oblige la JVM à diviser son invocation en deux sous-invocations : la première effectue une exécution d’entraînement (AOTMode=record), puis la seconde crée le cache AOT (AOTMode=create).

Lors de l’utilisation de cette option, la JVM crée un fichier temporaire pour la configuration AOT et supprime ce fichier une fois terminé.

Une nouvelle variable d’environnement, JDK_AOT_VM_OPTIONS, peut être utilisée pour passer des options de ligne de commande qui s’appliquent spécifiquement à la création de cache (AOTMode=create), sans affecter l’exécution de l’entraînement (AOTMode=record). La syntaxe est la même que pour la variable d’environnement JAVA_TOOL_OPTIONS existante. Cela permet au flux de travail en une étape de s’appliquer même dans les cas d’utilisation où il peut sembler que deux étapes sont nécessaires en raison de différences dans les options de ligne de commande.

Il est aussi toujours possible pour certains cas d’utilisation, où il peut être préférable d’utiliser deux étapes pour créer un cache AOT, de spécifier explicitement le mode AOT à chaque fois.

La JVM HotSpot exécute le byte code en utilisant plusieurs modes, notamment :

Au démarrage, la JVM interprète le bytecode. La mise en œuvre des modes C1 et C2 requiert un délai initial nommé temps de chauffe (warmup) pendant lequel le code est exécuté en mode interprété et la JVM capture des informations sous la forme de profils d’exécution de méthodes. Le JIT analyse le code exécuté et identifie les portions de code fréquemment exécutées, appelées « points chauds » (hot spots d’où le nom de la JVM).

Lorsque ces portions atteignent un certain seuil, elles sont compilées dynamiquement en code natif, permettant ainsi d’améliorer grandement les performances d’exécution tout en gardant un compromis sur le temps de démarrage. Malheureusement ces mécanismes consomment de la ressource et du temps et doivent être réexécutés à chaque démarrage de la JVM

Le but de la JEP 515 est d’améliorer le temps de préchauffage (warmup) de l’exécution d’une application dans une JVM HotSpot en rendant instantanément disponibles les profils d’exécution de méthodes, d’une exécution précédente de l’application, au démarrage de la JVM HotSpot.

Cela permet au compilateur JIT de générer du code natif immédiatement au démarrage de l’application, plutôt que d’avoir à attendre que les profils soient collectés durant le temps de préchauffage.

Pour cela le cache AOT, introduit par la JEP 483, est enrichi pour collecter des profils d’exécutions de méthodes lors du temps de préchauffage. Tout comme le cache AOT stocke actuellement les classes que la JVM aurait autrement besoin de charger et de lier au démarrage, le cache AOT stocke désormais également les profils de méthodes que la JVM aurait autrement besoin de collecter dans la première partie de l’exécution d’une application. Par conséquent, les exécutions de l’application sont à la fois plus rapides au démarrage et plus rapides pour atteindre des performances optimales.

Les profils mis en cache utilisés au démarrage n’empêchent pas le profilage supplémentaire pendant les exécutions de l’application. C’est essentiel, car le comportement d’une application peut diverger de ce qui a été observé précédemment. Même avec des profils mis en cache, la JVM HotSpot continue de profiler et d’optimiser l’application au fur et à mesure de son exécution, en fusionnant les avantages des profils AOT, du profilage en ligne et de la compilation JIT.

L’effet des profils mis en cache est que le JIT s’exécute plus tôt et avec plus de précision, en utilisant les profils pour optimiser les méthodes chaudes (hot methods) afin que l’application connaisse une période de préchauffage plus courte. Les tâches du JIT sont intrinsèquement parallèles, de sorte que le temps de préchauffage peut être court lorsque suffisamment de ressources matérielles sont disponibles.

Le but de la JEP 518 est d’améliorer la stabilité du JDK Flight Recorder (JFR) lorsqu’il échantillonne de manière asynchrone des piles de threads Java.

Le mécanisme d’échantillonnage de JFR a été repensé pour éviter de s’appuyer sur des heuristiques d’analyse de stacks risquées. Pour cela, il parcourt les stacks d’appels uniquement aux safepoints, tout en minimisant les biais induits par les safepoints.

Pour éviter le problème de biais des safepoints, des échantillons sont prélevés en coopération par un thread d’échantillonnage de JFR qui suspend le thread cible. Plutôt que d’essayer d’analyser la pile immédiatement, il enregistre simplement des informations dans une queue du thread local et reprend l’exécution thread.

La cible s’exécute normalement jusqu’à son prochain safepoint. À ce moment-là, le code de gestion du safepoint inspecte la queue.

S’il trouve des informations d’échantillonnage, il reconstruit pour chacune d’entre elles une stacktrace, en ajustant le biais des safepoints, et émet un événement JFR d’échantillonnage.

En plus d’être plus sûre, cette approche présente plusieurs autres avantages :

Cette approche fonctionne bien lorsque le thread cible exécute du code Java, qu’il soit interprété ou compilé, mais pas lorsque le thread cible exécute du code natif. Dans ce cas, JFR continue d’utiliser l’approche précédente.

Les headers compacts d’objets ont été intégrés à titre expérimental via la JEP 450 dans le JDK 24. Leur but est de réduire la taille des headers des objets à 64 bits (8 octets) sur les plateformes 64-bit x64 et AArch64. L’activation de cette fonctionnalité réduit l’encombrement du heap Java et offre potentiellement des avantages en termes de performances.

Le but de la JEP 519 est de modifier le statut de la fonctionnalité d’expérimentale à produit. Il n’est donc plus nécessaire d’utiliser l’option -XX:+UnlockExperimentalVMOptions pour demander son activation qui doit toujours être faite de manière explicite.

La fonctionnalité reste cependant désactivée par défaut dans cette version, mais pourrait devenir par défaut dans une version ultérieure.

Pour prendre en charge l’utilisation des en-têtes d’objets compacts, deux archives CDS supplémentaires pour l’image JDK appelées classes_coh.jsa et classes_nocoops_coh.jsa sont fournies pour permettre des performances de démarrage équivalentes lorsque l’option UseCompactObjectHeaders est activée.

Le but de la JEP 520 est d’enrichir le JDK Flight Recorder (JFR) avec des fonctionnalités pour le chronométrage et le traçage des méthodes via l’instrumentation du bytecode :

Deux nouveaux événements JFR sont ajoutés : jdk.MethodTiming et jdk.MethodTrace. Ils acceptent tous deux un filtre pour sélectionner les méthodes à chronométrer et à tracer.

Le filtre est spécifié sous la forme utilisant la même syntaxe que celle d’une référence de méthode dans le code source. Au démarrage, la JVM instrumente cette méthode en injectant du bytecode pour émettre les événements.

Exemple pour tracer les exécutions de la méthode traiter() de la classe DemoJEP520

Il est possible d’afficher les événements émis dans l’enregistrement par exemple avec la commande jfr du JDK en filtrant sur ceux de type jdk.MethodTrace.

Les fichiers de configuration default.jfc et profile.jfc sont enrichis avec deux nouvelles options, method-timing et method-trace, qui contrôlent les paramètres de filtre pour les événements jdk.MethodTiming et jdk.MethodTrace :

Les commandes jfr view et jcmd <pid> JFR.view sont améliorées pour afficher les résultats de chronométrage et de traçage des méthodes.

Il est possible de filtrer sur les blocs d’initialisation statique en utilisant ::<clinit>.

En plus d’une méthode, un filtre peut nommer une classe, auquel cas toutes les méthodes de la classe sont chronométrées ou tracées.

Un filtre peut également concerner une annotation. Cela fait que toutes les méthodes annotées avec l’annotation, et toutes les méthodes de toutes les classes annotées avec l’annotation, sont chronométrées ou tracées.

Par exemple, pour voir le nombre de fois qu’un endpoint REST invoqué via le verbe GET et développé avec JAX-RS est appelé, et mesurer le temps d’exécution :

S’il y a besoin de chronométrer ou de tracer plusieurs méthodes, il est possible de créer un fichier de configuration distinct pour les configurer toutes :

Il est ensuite possible de l’utiliser en conjonction avec la configuration par défaut :

Le mode générationnel de Shenandoah a été intégré à titre expérimental via la JEP 404 dans le JDK 24.

Le but de la JEP 521 est de modifier le mode générationnel du ramasse-miettes Shenandoah d’une fonctionnalité expérimentale à une fonctionnalité produit.

Il n’est donc plus nécessaire d’utiliser l’option -XX:+UnlockExperimentalVMOptions pour demander l’activation du mode générationnel de Shenandoah.

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 la JVM HotSpot du JDK 25.

La commande jar --validate a été améliorée pour identifier et générer un message d’avertissement pour :

Sous certaines conditions, le compilateur javac pouvait modifier des fichiers jar ou zip sur le chemin d’accès aux classes, en y écrivant des classfiles.

Ces conditions sont :

Ce n’est plus le cas dans le JDK 25. Les fichiers .class ne seront jamais écrits dans des fichiers jar ou zip. Ceux qui auraient dû être écrits dans un fichier jar ou zip seront placés dans le répertoire de travail actuel. Cela imite le comportement du JDK 8.

Dans le code source Java, les caractères littéraux de ne peuvent contenir qu’un seul caractère UTF-16. Le compilateur javac acceptait à tort les caractères littéraux composés de deux caractères de substitution UTF-16, n’utilisant que le premier caractère et ignorant le second caractère.

Exemple : le fichier DemoSurrogateUFT16.java .Le fichier .java

Ce fichier compile correctement avec un JDK24

Cela a été corrigé dans le JDK 25 : le compilateur javac produira une erreur de compilation lorsqu’il détectera un caractère littéral composé de deux caractères de substitution UTF-16.

Le flag -Xlint de javac est utilisé pour activer ou désactiver les catégories d’avertissements générés lors de la compilation.

Par exemple :

Historiquement, l’utilisation du flag -Xlint:none a également comme effet de bord invisible de désactiver tous les avertissements non obligatoires, exactement comme si le flag -nowarn était également utilisé.

En conséquence, l’effet d’un flag comme -Xlint:none,serial était simplement de désactiver tous les avertissements non obligatoires. En particulier, aucun avertissement dans la catégorie serial n’était généré.

Exemple : la classe DemoXlintNone.java .Le fichier .java

Exemple : compilation avec un JDK 24

Dans le JDK 25, -Xlint:none désactive simplement toutes les catégories, et un flag comme -Xlint:none,serial permet aux avertissements de type serial d’apparaître comme prévu.

Exemple : compilation avec un JDK 25

Avant le JDK 25, le compilateur javac permettait dans certains cas d’utiliser des classes dans le type pour des expressions Lambda.

Exemple : le fichier DemoLambdaClasse.java .Le fichier .java

Ce code compile avec le JDK 24, mais une exception est levée à l’exécution puisque le type de la Lambda n’est pas une interface fonctionnelle.

À partir du JDK 25, le compilateur javac générera une erreur pour les expressions Lambda dont le type contient une classe.

Comme l’indique le message d’erreur du compilateur, il est cependant toujours possible d’utiliser le type Object avec une intersection avec une interface fonctionnelle.

Exemple : le fichier DemoLambdaClasse.java .Le fichier .java

Ce code compile et s’exécute correctement.

L’option -Xprint de la commande javac a été mise à jour pour inclure les limites des types génériques et java.lang.Object en tant que supertype si le supertype est annoté.

Avec un JDK 24, l’utilisation de l’option -Xprint de javac sur ce fichier affiche :

Avec un JDK 25, l’utilisation de l’option -Xprint de javac sur ce fichier affiche :

Dans les programmes Java, chaque instance d’une classe interne a une instance qui l’englobe immédiatement. Lorsqu’une classe interne est instanciée avec le mot-clé new, l’instance immédiatement englobante est passée au constructeur de la classe interne via un paramètre non visible dans le code source. La spécification du langage Java (§15.9.4) exige que l’instance englobante immédiate ne soit pas null.

Avant le JDK 25, javac insérait une vérification de la valeur non null sur l’instance immédiatement englobante avant qu’elle ne soit transmise au constructeur de la classe interne. Aucune vérification de la valeur non null n’était effectuée dans le corps du constructeur de la classe interne. En conséquence, il était possible d’utiliser l’API Reflection, par exemple java.lang.reflect.Constructor::newInstance, ou des fichiers de classe spécialement conçus pour invoquer le constructeur d’une classe interne avec null comme instance immédiatement englobante. Cela peut entraîner des erreurs inattendues du programme.

À partir du JDK 25, javac insère une vérification de la valeur non null supplémentaire sur l’instance qui l’englobe immédiatement dans le corps du constructeur de la classe interne. Par conséquent, il n’y a aucun moyen d’instancier une classe interne avec null comme instance immédiatement englobante.

Dans le cas rare où il est nécessaire d’exécuter du code hérité qui passe null en tant qu’instance immédiatement englobante, il est possible d’utiliser, à ses risques et périls, l’option non prise en charge -XDnullCheckOuterThis=false.

Cela empêche javac d’insérer la vérification de valeur non null supplémentaire dans les corps des constructeurs de la classe interne.

La documentation API générée par l’outil javadoc ne définit plus le focus du clavier sur le champ de saisie de recherche lors du chargement de la page.

Au lieu de cela, il fournit des raccourcis clavier pour gérer le focus du clavier :

De plus, le contenu de la barre latérale et de la page de recherche peut désormais être parcouru à l’aide de la touche Tab et des touches fléchées.

L’outil javadoc propose une nouvelle option --syntax-highlight pour activer la coloration syntaxique dans les balises \{@snippet} et les éléments HTML <pre>.

La Javadoc peut être générée avec la coloration syntaxique du code :

L’option ne prend aucun argument et ajoute la bibliothèque Highlight.js à la documentation générée dans une configuration qui prend en charge les fragments de code Java, Properties, JSON, HTML et XML.

L’outil javadoc traite désormais les classes et les interfaces des packages qui ne sont pas exportés ou exportés avec un export qualifié comme cachées, à moins qu’elles ne soient explicitement incluses dans la documentation.

Ces classes et interfaces n’apparaissent pas dans la documentation générée, même si elles sont étendues ou implémentées par un type documenté. D’autres instances de types cachés sont les types private ou package-private, ou les types marqués avec le tag @hidden de JavaDoc.

L’outil javadoc supprime désormais l’indentation accessoire dès le début des lignes dans les commentaires de documentation traditionnels, comme il le fait déjà dans les commentaires de documentation en Markdown. Cela permet d’éviter les caractères d’espacement involontaires dans les exemples de code préformatés avec le tag HTML <pre> en préservant l’indentation relative des lignes.

Avant le JDK 25, jpackage incluait des liaisons de service pour les images de runtime.

À partir du JDK 25, jpackage n’inclut plus les liaisons de service pour une image de runtime qu’il crée. Par conséquent, les images de runtime générées par jpackage peuvent ne pas inclure le même ensemble de modules que dans les versions précédentes.

Le comportement précédent peut être obtenu en ajoutant l’option --bind-services aux options de jlink utilisées par jpackage :

Le but est d’introduire une API pour les fonctions de dérivation de clé, en anglais Key Derivation Function (KDF), qui font partie du standard PKCS # 11.

Les algorithmes cryptographiques permettent de dériver des clés à partir d’une clé secrète et d’autres données via la nouvelle classe javax.crypto.KDF avec un support de l’algorithme HKDF.

Elle a été introduite en preview dans le JDK 24 via la JEP 478.

Elle est proposée en standard dans le JDK 25 via la JEP 510, sans changement.

Le résultat de l’exécution de la classe :

Le but de la JEP 470 est d’introduire en preview 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 : par exemple pour une clé publique, elle est entourée d’un en-tête contenant BEGIN PUBLIC KEY et d’un pied contenant END PUBLIC KEY.

L’API proposée contient notamment :

Exemple :

Le fichier DemoJEP470PEMClePrivee.java .Le fichier .java

Résultat de l’exécution

Pour une clé privée, il est possible et recommandé de la chiffrer en utilisant la méthode PEMEncoder::withEncryption et de déchiffrer avec PEMDecoder::withDecryption qui attendent en paramètre le mot de passe à utiliser.

La méthode PEMDEcoder::withFactory retourne une copie de l’instance de PEMDecoder qui utilise les implémentations KeyFactory et CertificateFactory du Provider fourni en paramètre pour produire les objets cryptographiques.

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