JDK 12: les nouvelles fonctionnalités de Java 12

La version de production de Java Development Kit 12, basée sur Java SE (Standard Edition) 12, est désormais disponible. Les versions JDK 12 sont disponibles auprès d'Oracle pour Linux, Windows et MacOS. 

Où télécharger le JDK 12

Vous pouvez télécharger le JDK 12 à partir du site Web Java.net.

Les versions open source sont fournies sous la licence publique générale GNU v2, avec une exception Classpath. Les versions commerciales du JDK 12 d'Oracle peuvent être trouvées sur le réseau Oracle Technology sous une licence non open source.

Nouvelles fonctionnalités de Java 12

Collecteur d'ordures Shenandoah

Java 12 ajoute Shenandoah, un algorithme expérimental de ramassage des ordures, pour réduire les temps de pause du ramassage des ordures en effectuant un travail d'évacuation en même temps que l'exécution de threads Java. Shenandoah fournit un algorithme approprié pour les applications qui valorisent la réactivité et de courtes pauses prévisibles. L'intention n'est cependant pas de résoudre tous les problèmes de pause JVM.

Red Hat prend actuellement en charge Shenandoah sur les architectures Aarch64 et AMD64.

Collectes mixtes abandonnées pour le garbage collector G1

Java 12 rend les collections mixtes G1 annulables si elles peuvent dépasser la cible de pause. Un objectif de G1 était d'atteindre un objectif de temps de pause fourni par l'utilisateur pour ses pauses de collecte.

Auparavant, un moteur d'analyse avancé sélectionnait la quantité de travail à effectuer lors d'une collecte. Le résultat était un ensemble de régions appelées ensemble de collections. Une fois l'ensemble déterminé et la collecte commencée, G1 a collecté tous les objets vivants dans les régions des collections dans toutes les régions sans s'arrêter. Mais cela pourrait conduire G1 à dépasser l'objectif de temps de pause si l'heuristique d'une application choisissait un ensemble de collections trop volumineux.

Un mécanisme était nécessaire pour détecter le moment où l'heuristique sélectionnait à plusieurs reprises une quantité de travail incorrecte pour les collections et, si cela se produisait, demander à G1 d'effectuer le travail de collecte de manière incrémentielle par étapes, la collecte pouvant être abandonnée après chaque étape. Le mécanisme introduit dans Java 12 permet à G1 d'atteindre plus souvent l'objectif de temps de pause.

Retour rapide de la mémoire engagée inutilisée

Java 12 améliore G1 pour renvoyer automatiquement la mémoire de tas Java au système d'exploitation lorsqu'il est inactif. Cette mémoire est libérée dans un délai raisonnable lorsque l'activité de l'application est très faible.

Auparavant, G1 renvoyait uniquement la mémoire du tas lors d'un garbage collection complet ou pendant un cycle simultané. Avec G1 essayant d'éviter le garbage collection complet, ne déclenchant qu'un cycle simultané basé sur l'occupation du tas et l'activité d'allocation, il ne retournerait pas la mémoire du tas dans de nombreux cas à moins d'être forcé de le faire en externe. Ce comportement était désavantageux dans les environnements de conteneurs où les ressources sont payées à l'utilisation. Même lorsque la machine virtuelle Java n'utilise qu'une fraction de sa mémoire attribuée en raison de l'inactivité, G1 a conservé le tas complet. Ainsi, les clients payaient toutes les ressources en permanence et les fournisseurs de cloud ne pouvaient pas utiliser pleinement leur matériel.

Avec Java 12, la JVM peut détecter les phases de sous-utilisation du tas et réduire automatiquement son utilisation pendant ce temps. 

API de constantes JVM

Cette API modélise les descriptions nominales des fichiers de classe de clé et des artefacts d'exécution, en particulier les constantes chargeables à partir du pool de constantes. Java 12 définit une famille de types de référence symbolique basés sur des valeurs dans un nouveau package,, java.lang.invoke.constantpour décrire chaque type de constante chargeable.

Des pools de constantes existent dans chaque classe Java, stockant des opérandes et des instructions de bytecode dans la classe. Les entrées du pool de constantes décrivent soit des artefacts d'exécution tels que des classes et des méthodes, soit des valeurs simples telles que des chaînes et des entiers. Ces entrées sont appelées constantes chargeables.

Les programmes qui manipulent des fichiers de classe doivent modéliser des instructions de bytecode et à leur tour des constantes chargeables. Mais l'utilisation de types Java standard pour modéliser des constantes chargeables est inadéquate. Cela peut être acceptable pour une constante chargeable qui décrit une chaîne, mais c'est problématique pour une constante chargeable qui décrit une classe, car la production d'un Classobjet «en direct» dépend de l'exactitude et de la cohérence du chargement de classe. Le chargement de classe, cependant, a de nombreuses dépendances environnementales et modes de défaillance.

Ainsi, les programmes qui traitent des constantes chargeables pourraient être simplifiés s'ils pouvaient manipuler des classes et des méthodes et des artefacts moins connus tels que des poignées de méthode et des constantes calculées dynamiquement sous une forme symbolique nominale. Ainsi, l'API des constantes JVM offre aux bibliothèques et aux outils un moyen standard unique de décrire les constantes chargeables.

Amélioration du démarrage, du CDS et du garbage collection

Java 12 améliore le processus de construction JDK pour générer une archive de partage de données de classe (CDS) par défaut, à l'aide de la liste de classes par défaut, sur les plates-formes 64 bits. Cela améliore le temps de démarrage prêt à l'emploi et élimine le besoin de courir -Xshare:dumppour bénéficier du CDS. Le processus de construction JDK a été modifié pour s'exécuter java-xshare:dumpaprès la liaison de l'image.

Des options de ligne de commande supplémentaires ont été incluses pour affiner les temps de tas de garbage collection afin d'améliorer la disposition de la mémoire pour les cas courants. Les utilisateurs ayant des exigences plus avancées, telles que des listes de classes personnalisées qui incluent des classes d'application et différentes configurations de garbage collection, peuvent toujours créer une archive CDS personnalisée.

Nombre réduit de ports ARM

Java 12 supprime toutes les sources liées au arm64port tout en conservant les ARM 32 bits et 64 bits aarch64. La suppression de ce port permettrait aux contributeurs de concentrer leurs efforts sur une seule implémentation ARM 64 bits et d'éliminer le travail en double qui résulterait du maintien de deux ports. Actuellement, deux ports ARM 64 bits se trouvent dans le JDK.

Changer d'expressions

Les expressions de commutation simplifient le codage en étendant l' switchinstruction afin qu'elle puisse être utilisée comme une instruction ou une expression. Cela permet à la fois aux instructions et aux expressions d'utiliser une portée et un comportement de flux de contrôle «traditionnels» ou «simplifiés». Ces changements se traduisent par un codage «quotidien» plus simple et préparent la voie à l’utilisation de la correspondance de motifs dans switch.

Au fur et à mesure que les constructeurs Java prennent en charge la correspondance de modèles, les irrégularités de l' switchinstruction Java  sont devenues des obstacles. Celles-ci incluent le comportement de flux de contrôle par défaut des blocs de commutation; la portée par défaut des blocs de commutation, dans laquelle le bloc est traité comme une seule portée; et commutateur fonctionnant uniquement comme une instruction. La conception actuelle de l' switchinstruction de Java suit de près les langages tels que C ++ et, par défaut, prend en charge la sémantique fallthrough. Ce flux de contrôle a été utile pour écrire du code de bas niveau. Mais lorsque le commutateur est utilisé dans des contextes de niveau supérieur, sa nature sujette aux erreurs commence à l'emporter sur la flexibilité.

Suite de référence de base

JDK 12 comprend une suite de base de microbenchmarks, qui ont été ajoutés au code source de la plate-forme. L'objectif est de permettre aux développeurs d'exécuter plus facilement des benchmarks existants ou d'en créer de nouveaux.

La proposition de suite microbenchmarks, créée en juillet 2014 et mise à jour début novembre 2018, était étayée par le Java Microbenchmark Harness (JMH), pour la création de benchmarks écrits en Java et dans d'autres langages JVM. La suite est colocalisée avec le code source JDK dans un répertoire unique, avec des développeurs capables d'ajouter facilement de nouveaux benchmarks.

Ce n'était pas un objectif de fournir des repères pour les nouvelles fonctionnalités du JDK ou de créer un ensemble complet de repères couvrant tout le JDK. Notez également que la suite d'analyse comparative n'est pas requise pour les versions JDK normales, mais constitue une cible de construction distincte. 

La proposition appelait à la création d'une nouvelle page sur wiki.openjdk.java.net pour expliquer comment développer des benchmarks et décrire les exigences. Ces exigences exigeront le respect des normes de codage, des performances reproductibles et de la documentation.

Mises à jour du JDK 12

Les plans prévoient que le JDK 12 reçoive deux mises à jour avant d'être remplacé par le JDK 13 dans six mois. JDK 12 fait partie de la cadence de publication de six mois d'Oracle introduite avec JDK 9 en septembre 2017. JDK 12 est caractérisé comme une version de fonctionnalité, contrairement à JDK 11, qui est une version de support à long terme avec plusieurs années de support prévues.