JDK 15: les nouvelles fonctionnalités de Java 15

Java Development Kit 15, l'implémentation d'Oracle de la prochaine version de Java SE (Standard Edition), devient disponible en tant que version de production aujourd'hui, le 15 septembre 2020. Les points forts du JDK 15 incluent des blocs de texte, des classes cachées, une API d'accès à la mémoire étrangère, le Z Garbage Collector et des aperçus des classes scellées, des correspondances de modèles et des enregistrements.

JDK 15 n'est qu'une version à court terme, qui sera uniquement prise en charge avec Oracle Premier Support pendant six mois jusqu'à l'arrivée du JDK 16 en mars prochain. JDK 17, la prochaine version du support à long terme, qui sera prise en charge par Oracle pendant huit ans, devrait arriver dans un an, selon la cadence de publication d'Oracle de six mois pour les versions Java SE.

Les développeurs peuvent maintenant consulter le JDK 15 pour avoir une idée de ce que sera le JDK 17, a déclaré Georges Saab, président du groupe Oracle Java Platform. La version actuelle de LTS est JDK 11, qui est arrivée en septembre 2018. Les versions de LTS arrivent tous les trois ans. Le JDK 15 suit le JDK 14, sorti le 17 mars 2020. 

Les nouvelles fonctionnalités et modifications d'OpenJDK 15:

  • Un deuxième incubateur d'une API d'accès à la mémoire étrangère, qui permettrait aux programmes Java d'accéder en toute sécurité et efficacement à la mémoire étrangère en dehors du tas Java. L'API doit pouvoir fonctionner sur différents types de mémoire étrangère, tels que le tas natif, persistant et géré. De nombreux programmes Java accèdent à la mémoire étrangère, comme Ignite et MapDB. L'API aiderait à éviter le coût et l'imprévisibilité associés au garbage collection, à partager la mémoire entre les processus et à sérialiser et désérialiser le contenu de la mémoire en mappant les fichiers sur la mémoire. L'API Java ne fournit actuellement pas de solution satisfaisante pour accéder à la mémoire étrangère. Mais avec la nouvelle proposition, il ne devrait pas être possible pour l'API de compromettre la sécurité de la JVM. Cette capacité passe par une phase d'incubation antérieure dans JDK 14, avec des améliorations proposées dans JDK 15. 
  • Un aperçu des classes scellées. Avec les interfaces, les classes scellées limitent les autres classes ou interfaces qui peuvent les étendre ou les implémenter. Les objectifs de cette fonctionnalité incluent de permettre à l'auteur d'une classe ou d'une interface de contrôler quel code est responsable de son implémentation, de fournir un moyen plus déclaratif que les modificateurs d'accès pour restreindre l'utilisation d'une superclasse et de prendre en charge les futures directions de la correspondance de modèles en soutenant l'exhaustivité analyse des modèles.
  • Suppression du code source et prise en charge de build pour les ports Solaris / SPARC, Solaris / x64 et Linux / SPARC, qui ont été déconseillés pour suppression dans JDK 14 dans le but de les supprimer dans une version ultérieure. De nombreux projets et fonctionnalités en développement tels que Valhalla, Loom et Panama nécessitent des modifications importantes de l'architecture du processeur et du code spécifique au système d'exploitation. La suppression de la prise en charge des ports Solaris et SPARC permettra aux contributeurs de la communauté OpenJDK d'accélérer le développement de nouvelles fonctionnalités qui feront progresser la plate-forme. Solaris et SPARC ont été remplacés ces dernières années par le système d'exploitation Linux et les processeurs Intel.
  • Les enregistrements, qui sont des classes qui agissent comme des supports transparents pour des données immuables, seraient inclus dans une deuxième version préliminaire du JDK 15, après avoir fait ses débuts en tant qu'aperçu précoce dans JDK 14. Les objectifs du plan incluent la conception d'une construction orientée objet qui agrégation simple de valeurs, aidant les programmeurs à se concentrer sur la modélisation de données immuables plutôt que sur un comportement extensible, implémentant automatiquement des méthodes basées sur les données telles que les égaux et les évaluateurs, et la préservation des principes Java de longue date tels que le typage nominal et la compatibilité de la migration. Les enregistrements peuvent être considérés comme des tuples nominaux. 
  • Signatures cryptographiques basées sur l'algorithme de signature numérique Edwards-Curve (EdDSA). EdDSA est un schéma de courbe elliptique moderne avec des avantages par rapport aux schémas de signature existants dans le JDK. EdDSA sera implémenté uniquement dans le fournisseur SunEC. EdDSA est en demande en raison de sa sécurité et de ses performances améliorées par rapport aux autres schémas de signature; il est déjà pris en charge dans les bibliothèques de chiffrement telles que OpenSSL et BoringSSL.
  • Réimplémenter l'API DatagramSocket héritée en remplaçant les implémentations sous - jacentes des  java.net.datagram.Socketet java.net.MulticastSocketAPI avec des implémentations plus simples et plus modernes que 1. sont faciles à déboguer et à maintenir et 2. le travail avec des fils virtuels actuellement à l'étude dans le projet Loom. Le nouveau plan fait suite à la proposition d'amélioration JDK 353 qui a réimplémenté l'ancienne API Socket. Les implémentations actuelles java.net.datagram.Socketet java.net.MulticastSocketremontent à JDK 1.0 et à une époque où IPv6 était encore en développement. Ainsi, la mise en œuvre actuelle de  MulticastSocket tente de réconcilier IPv4 et IPv6 de manière difficile à maintenir.
  • Désactivation du verrouillage biaisé par défaut et désapprobation de toutes les options de ligne de commande associées. L'objectif est de déterminer la nécessité d'une prise en charge continue de l'optimisation coûteuse à maintenir de la synchronisation héritée du verrouillage biaisé, qui est utilisée dans la machine virtuelle HotSpot pour réduire la surcharge du verrouillage incontrôlé. Bien que certaines applications Java puissent voir une régression des performances avec le verrouillage biaisé désactivé, les gains de performances du verrouillage biaisé sont généralement moins évidents qu'ils ne l'étaient auparavant.
  • Un deuxième aperçu de la correspondance de modèles pour instanceof, après un aperçu précédent dans JDK 14. La correspondance de modèles permet à la logique commune d'un programme, principalement l'extraction conditionnelle de composants à partir d'objets, d'être exprimée plus facilement et de manière plus concise. Des langages tels que Haskell et C # ont adopté la correspondance de modèles pour sa brièveté et sa sécurité.
  • Les classes cachées, c'est-à-dire les classes qui ne peuvent pas être utilisées directement par le bytecode d'autres classes, sont destinées à être utilisées par des frameworks qui génèrent des classes à l'exécution et qui les utilisent indirectement par réflexion. Une classe masquée peut être définie comme membre d'une imbrication de contrôle d'accès et peut être déchargée indépendamment des autres classes. La proposition améliorerait l'efficacité de tous les langages sur la JVM en permettant à une API standard de définir des classes cachées qui ne sont pas détectables et qui ont un cycle de vie limité. Les cadres à l'intérieur et à l'extérieur du JDK seraient capables de générer dynamiquement des classes qui pourraient à la place définir des classes cachées. De nombreux langages basés sur la JVM reposent sur la génération de classes dynamiques pour plus de flexibilité et d'efficacité. Les objectifs de cette proposition sont les suivants: permettre aux frameworks de définir des classes comme des détails d'implémentation non découvrables du framework,ils ne peuvent donc pas être liés par d'autres classes ni découverts par réflexion; prise en charge de l'extension d'un nid de contrôle d'accès avec des classes non découvrables; et la prise en charge du déchargement agressif des classes non découvrables, de sorte que les frameworks ont la flexibilité d'en définir autant que nécessaire. Un autre objectif est de désapprouver l'API non standard, misc.Unsafe::defineAnonymousClass, avec l'intention de devenir obsolète pour suppression dans une version ultérieure. De plus, le langage Java ne doit pas être modifié suite à cette proposition.
  • Le Z Garbage Collector (ZGC) passe d'une fonctionnalité expérimentale à un produit dans le cadre de cette proposition. Intégré au JDK 11, arrivé en septembre 2018, ZGC est un garbage collector évolutif à faible latence. ZGC a été présenté comme une capacité expérimentale parce que les développeurs de Java ont décidé qu'une fonctionnalité de cette taille et de cette complexité devait être introduite avec soin et progressivement. Depuis lors, un certain nombre d'améliorations ont été ajoutées, allant du déchargement de classe simultané, de la désactivation de la mémoire inutilisée et de la prise en charge du partage de données de classe à une meilleure prise de conscience NUMA et au pré-toucher de tas multi-thread. En outre, la taille maximale du tas a été augmentée de quatre téraoctets à 16 téraoctets. ZGC répond aux problèmes de performances dans les applications qui impliquent des quantités massives de données, telles que l'apprentissage automatique,où les utilisateurs veulent être sûrs que le traitement des données ne sera pas soumis à l'imprévisibilité ou à de longues pauses en raison du ramassage des ordures. Les plates-formes prises en charge incluent Linux, Windows et MacOS.
  • Les blocs de texte, prévisualisés à la fois dans JDK 14 et JDK 13, sont destinés à simplifier la tâche d'écriture de programmes Java en facilitant l'expression de chaînes qui s'étendent sur plusieurs lignes de code source, tout en évitant les séquences d'échappement dans les cas courants. Un bloc de texte est un littéral de chaîne multiligne qui évite le recours à la plupart des séquences d'échappement, met automatiquement en forme la chaîne de manière prévisible et offre au développeur le contrôle du format lorsqu'il le souhaite. Un objectif de la proposition de blocs de texte est d'améliorer la lisibilité des chaînes dans les programmes Java qui désignent du code écrit dans des langages non Java. Un autre objectif est de prendre en charge la migration à partir de littéraux de chaîne en stipulant que toute nouvelle construction peut exprimer le même ensemble de chaînes qu'un littéral de chaîne, interpréter les mêmes séquences d'échappement et être manipulé de la même manière qu'un littéral de chaîne.Les développeurs d'OpenJDK espèrent ajouter des séquences d'échappement pour gérer les espaces blancs explicites et le contrôle de nouvelle ligne.
  • Le ramasse-miettes Shenandoah à faible temps de pause deviendrait une fonction de production et sortirait du stade expérimental. Il avait été intégré au JDK 12 il y a un an.
  • Suppression de Nashorn, qui a fait ses débuts dans JDK 8 en mars 2014, mais a depuis été rendu obsolète par des technologies telles que GraalVM. La proposition OpenJDK 15 appelle à la suppression des API Nashorn et de l'outil de ligne de commande jjs utilisé pour appeler Nashorn.
  • Abandon du mécanisme d'activation RMI, pour suppression future. Le mécanisme d'activation RMI est une partie obsolète de RMI qui est facultative depuis Java 8. L'activation RMI impose une charge de maintenance continue. Aucune autre partie de RMI ne sera obsolète.