JDK 21: The new features in Java 21

Prévu pour être publié en septembre en tant que prochaine version de support à long terme de l’implémentation Java standard d’Oracle, le kit de développement Java (JDK) 21 propose désormais 11 fonctionnalités officiellement proposées, avec trois autres fonctionnalités ajoutées ces derniers jours.

Les nouvelles fonctionnalités incluent un ramasse-miettes générationnel Shenandoah, des classes sans nom et des méthodes principales d’instance, ainsi que des variables et des modèles sans nom. Séparément, JDK 21 modifiera également la façon dont les noms de réseau sont attribués aux interfaces réseau dans Windows.

Les trois nouvelles fonctions proposées s’ajoutent aux huit précédemment proposées : générationnel ZGC (Z Garbage Collector), registration patterns, pattern matching for switch expressions et instructions, une API vectorielle, des collections séquencées, des threads virtuels, un aperçu du modèle de chaîne et un troisième aperçu d’une fonction externe et d’une API mémoire.

Les binaires Early Access sous licence GPL sont disponibles sur jdk.java.net. Oracle publie de nouvelles versions de Java standard tous les six mois, la plus récente, JDK 20, arrivant le 21 mars. Les propositions spécifiques pour JDK 21 incluent jusqu’à présent :

• Generational Shenandoah, une proposition visant à améliorer le Shenandoah GC avec des capacités de collecte de génération expérimentales pour améliorer les performances durables, la résistance aux surtensions et l’utilisation de la mémoire. L’objectif principal de la proposition est de fournir un mode générationnel expérimental sans casser la Shenandoah non générationnelle, avec l’intention de faire du mode générationnel le mode par défaut dans une future version. D’autres objectifs incluent la réduction de l’empreinte mémoire soutenue sans sacrifier les faibles pauses GC, la réduction de l’utilisation du processeur et de l’alimentation, le maintien de performances élevées et la poursuite de la prise en charge des pointeurs d’objet compressés. Initialement, la proposition prendrait en charge x64 et AArch64, avec la prise en charge d’autres jeux d’instructions ajoutés au fur et à mesure que le mode expérimental progresse vers la préparation. L’objectif n’est pas de remplacer la Shenandoah non générationnelle, qui continuera d’être le mode de fonctionnement par défaut sans régression des performances ou des fonctionnalités. Améliorer les performances de toutes les charges de travail imaginables n’est pas non plus un objectif.
• Un aperçu des classes sans nom et des méthodes d’instance principale, pour faire évoluer le langage afin que les étudiants puissent écrire leurs premiers programmes Java sans avoir besoin de comprendre les fonctionnalités du langage conçues pour les grands programmes. Loin d’utiliser un dialecte Java distinct, les étudiants peuvent écrire des instructions simplifiées pour les programmes d’une seule classe, puis développer de manière transparente les programmes pour utiliser des fonctionnalités plus avancées à mesure que leurs compétences augmentent. L’intention est de fournir un chemin fluide vers Java.
• Un aperçu des modèles et des variables sans nom, pour améliorer le langage avec des modèles et des variables sans nom. Les modèles sans nom correspondent à un composant de registre sans indiquer le nom ou le type du composant, tandis que les variables sans nom peuvent être initialisées mais pas utilisées. Les deux sont indiqués par un caractère de soulignement, _. Cette proposition vise à améliorer la lisibilité des modèles d’enregistrement en supprimant les modèles imbriqués inutiles et à améliorer la maintenabilité de tout le code en identifiant les variables qui doivent être déclarées mais ne seront pas utilisées.
• Le ZGC générationnel est destiné à améliorer les performances des applications en étendant le ZGC pour maintenir des générations distinctes pour les anciens et les nouveaux objets. Les jeunes objets ont tendance à mourir jeunes, et séparer les générations permettra à ZGC de les collecter plus souvent. Les applications s’exécutant avec ZGC générationnel devraient bénéficier des avantages suivants : réduction des risques de verrous d’allocation, réduction de la surcharge de mémoire de tas requise et réduction de la surcharge du processeur de récupération de place. Ces avantages devraient se produire sans réduction significative des performances par rapport au ZGC non générationnel.
• Les modèles de registre, vus dans JDK 19 et JDK 20, déconstruiraient les valeurs de registre. Les modèles d’enregistrement et les modèles de type peuvent être imbriqués pour permettre une forme puissante, déclarative et composable de navigation et de traitement des données. Les objectifs de la proposition incluent l’extension de la correspondance de modèles pour déstructurer les instances de classe d’enregistrement et l’ajout de modèles imbriqués, permettant des requêtes de données plus composables. Cette fonctionnalité a évolué avec la correspondance de modèle pour le commutateur. Les modèles d’enregistrement dans le JEP actuel (proposition d’amélioration du JDK) proposent de finaliser la fonctionnalité avec d’autres améliorations basées sur l’expérience et les commentaires continus. Mis à part les changements éditoriaux mineurs, le principal changement depuis le deuxième aperçu est de supprimer la prise en charge des modèles d’enregistrement qui apparaissent dans l’en-tête d’un fichier amélioré. for déclaration. La fonction pourra être reproposée dans un futur JEP.
• Correspondance de modèle pour switch permet une switch expression ou déclaration à tester par rapport à une série de modèles, chacun avec une action spécifique, afin que les requêtes complexes orientées données puissent être exprimées de manière sûre et concise. Cette fonctionnalité a été proposée à l’origine dans JDK 17, puis affinée dans JDK 18, JDK 19 et JDK 20. Elle sera finalisée dans JDK 21 avec des améliorations supplémentaires basées sur les commentaires et l’expérience. Les principaux changements par rapport aux JEP précédents sont la suppression des modèles entre parenthèses et l’autorisation de constantes d’énumération qualifiées, telles que les constantes de cas avec switch expressions et déclarations. Les objectifs comprennent l’expansion de l’expressivité et de l’applicabilité de switch expressions et déclarations en autorisant l’apparition de modèles dans les étiquettes de cas, permettant une hostilité historique nulle de la part de switch soyez détendu quand vous le souhaitez et augmentez la sécurité de switch déclarations en exigeant ce modèle switch Les instructions couvrent toutes les valeurs d’entrée potentielles. Un autre objectif est de garantir l’existence switch les expressions et les instructions continuent à se compiler sans changement et sont exécutées avec une sémantique identique.
• Un sixième incubateur d’une API vectorielle pour exprimer des calculs vectoriels qui se compilent de manière fiable au moment de l’exécution en instructions vectorielles optimales sur les architectures de processeur prises en charge, atteignant des performances supérieures aux calculs scalaires équivalents. Cela a déjà été éclos dans JDK 16 à JDK 20. La dernière incarnation inclut des améliorations de performances et des corrections de bogues. Les objectifs de la proposition sont d’être clair et concis, d’être indépendant de la plate-forme et de fournir des performances de compilation et d’exécution fiables sur les architectures x64 et AArch64. D’autres objectifs incluent une rétrogradation gracieuse, lorsqu’un calcul vectoriel ne peut pas être entièrement exprimé au moment de l’exécution en tant que séquence d’instructions vectorielles, et l’alignement avec le projet Valhalla.
• La fonction externe et l’API de mémoire permettent aux programmes Java d’interagir avec le code et les données en dehors de l’environnement d’exécution Java. Grâce à l’invocation efficace de fonctions externes et à un accès sécurisé à la mémoire externe, cette API de prévisualisation permet aux programmes Java d’appeler des bibliothèques natives et de traiter des données natives sans la fragilité et le danger de Java Native Interface (JNI). L’API a déjà été introduite dans JDK 20, qui a fait ses débuts le mois dernier, et JDK 19, qui a été publié en septembre 2022. Les améliorations apportées à la dernière préversion incluent des chemins de mise en page améliorés avec un nouvel élément pour déréférencer les mises en page d’adresse, la gestion centralisée de la durée de vie des segments natifs dans le Arena interface, une implémentation alternative de l’éditeur de liens natif et la suppression de l’interface VaList. Les objectifs de la proposition incluent la facilité d’utilisation, les performances, la généralité et la sécurité. L’objectif n’est pas de réimplémenter JNI en plus de cette API ou de modifier JNI de quelque manière que ce soit.
• Les threads virtuels sont des threads légers qui promettent de réduire « considérablement » l’effort d’écriture, de maintenance et d’observation d’applications simultanées hautes performances. Les objectifs du plan incluent l’activation des applications serveur écrites dans le style simple de thread à la demande pour évoluer avec une utilisation matérielle quasi optimale, permettant au code existant qui utilise le lang.Thread API pour adopter des threads virtuels avec un minimum de modifications et permettre un débogage et un profilage faciles des threads virtuels avec les outils JDK actuels. Précédemment vus dans JDK 20 et JDK 19, les threads virtuels seront terminés dans JDK 21. Avec JDK 21, les threads virtuels prennent désormais en charge les variables locales de thread tout le temps et rendent impossible la création de threads virtuels qui n’ont pas ces variables. . La prise en charge garantie des variables locales de thread garantit que davantage de bibliothèques existantes peuvent être utilisées sans modification avec les threads virtuels et facilite la migration du code orienté tâche pour utiliser les threads virtuels.
• Les collections séquencées introduisent des interfaces pour représenter les collections avec un ordre de recherche défini. Chaque collection a des premier et deuxième éléments bien définis, et ainsi de suite, jusqu’au dernier élément. Des API uniformes sont fournies pour accepter le premier et le dernier élément et traiter les éléments dans l’ordre inverse. Ce qui motive la proposition est une situation où le framework de collections Java manque d’un type de collection pour représenter une séquence d’éléments avec un ordre d’occurrence défini. Il manque également un ensemble uniforme d’opérations qui s’appliquent à toutes ces collections. Ces lacunes ont été un problème et une source de plaintes. La proposition nécessite de définir des interfaces pour le séquencement des collections, des ensembles et des cartes, et de les adapter à la hiérarchie existante des types de collections. Toutes ces nouvelles méthodes ont des implémentations par défaut.
• Les modèles de chaîne, qui apparaîtront en tant que fonction d’aperçu, complètent les blocs de texte Java existants et les littéraux de chaîne en couplant le texte littéral avec des processeurs et des expressions intégrés pour produire des résultats spécialisés. Cette fonctionnalité de langage et cette API sont destinées à simplifier l’écriture de programmes Java en facilitant l’expression de chaînes contenant des valeurs calculées au moment de l’exécution. Il promet d’améliorer la lisibilité des expressions, d’améliorer la sécurité du programme, de maintenir la flexibilité et de simplifier l’utilisation des API qui acceptent les chaînes écrites dans des langages non Java. Permettre le développement d’expressions non-chaîne dérivées de la combinaison de texte littéral et d’expressions incorporées est également un objectif.

Outre ces JEP, les noms de réseau que le JDK attribue aux interfaces réseau sous Windows devraient changer dans le JDK 21, selon l’équipe Java d’Oracle. Les mainteneurs d’applications qui effectuent la multidiffusion réseau ou utilisent le java.net.NetworkInterface L’API est encouragée à prendre note du changement.

Le JDK synthétisait historiquement les noms des interfaces réseau dans Windows. Cela a été modifié pour utiliser les noms attribués par le système d’exploitation Windows. La modification peut affecter le code qui effectue une recherche d’interfaces réseau à l’aide de la NetworkInterface.GgetbyName(String-name) méthode.

Le calendrier de sortie proposé pour JDK 21 comprend des phases de liquidation qui auront lieu le 8 juin et le 20 juillet. L’ensemble de fonctionnalités est gelé dans les premières phases de réduction tandis que les corrections de bogues se poursuivent. Vient ensuite la version initiale et finale des versions candidates les 10 et 24 août, avec des corrections de bogues toujours possibles, suivie d’une disponibilité générale le 19 septembre.

En tant que version de support à long terme (LTS), JDK 21 bénéficierait de cinq ans de support Premier et d’un support étendu jusqu’en septembre 2031. La version LTS actuelle est JDK 17, publiée en septembre 2021. Les versions non LTS, telles que JDK 20 et JDK 19, ne reçoivent que six mois de support général et aucun support étendu.