Java 21 est arrivé en version de production avec 15 fonctionnalités, dont les threads virtuels, un ramasse-miettes générationnel Z et un mécanisme d’encapsulation clé API.
La dernière version Java Development Kit (JDK) 21 avec support à long terme (LTS) est arrivée en version de production. Basé sur Java 21, la dernière version de la plate-forme Java SE (Standard Edition), JDK 21 inaugure 15 fonctionnalités, dont une API de mécanisme d’encapsulation de clé, des threads virtuels et des aperçus de modèles de chaînes et de concurrence structurée.
JDK 21 est accessible depuis Oracle.com, avec un support disponible auprès d’Oracle. Ce dernier prendra en charge le JDK 21 pendant au moins 8 ans. La société a également annoncé que le support à long terme de Java 11, sorti il y a 5 ans, avait été étendu jusqu’en janvier 2032.
Oracle publie de nouvelles versions de Java standard tous les 6 mois. La version précédente, JDK 20, est arrivée le 21 mars. Les versions à long terme arrivent tous les 2 ans, entrecoupées de versions à court terme soutenues par 6 mois de support.
Les 15 fonctionnalités du JDK 21 incluent :
1-La concurrence structurée, en phase de préversion, simplifie la programmation simultanée via une API pour la concurrence structurée, traitant les groupes de tâches connexes exécutées dans différents threads comme une seule unité de travail. Cela rationalise la gestion et l’annulation des erreurs, améliorant ainsi la fiabilité et l’observabilité. La concurrence structurée était auparavant incubée dans le JDK 20 et le JDK 19, publiés respectivement en mars et septembre 2022 ; elle doit être présentée comme API d’aperçu dans le package java.util.concurrent. Le seul changement significatif cette fois-ci est que la méthode StructuredTaskScope::Fork(…) renvoie une [Sous-tâche] plutôt qu’un Future. Les objectifs de la concurrence structurée incluent la promotion d’un style de programmation simultanée capable d’éliminer les risques courants liés à l’annulation et à l’arrêt, tels que les fuites de threads et les retards d’annulation, ainsi que l’amélioration de l’observabilité du code simultané.
2-Les valeurs étendues, également en aperçu, permettront le partage de données immuables au sein et entre les threads. Elles sont préférées aux variables locales des threads, en particulier lors de l’utilisation d’un grand nombre de threads virtuels. Les variables locales de thread présentent des défauts de conception, notamment une mutabilité sans contrainte, une durée de vie illimitée et un héritage coûteux. Une valeur étendue permet aux données d’être partagées en toute sécurité entre les composants d’un programme volumineux sans recourir à des arguments de méthode. Cette proposition a été incubée dans le JDK 20. Les objectifs du plan incluent la facilité d’utilisation, la compréhensibilité, la robustesse et les performances.
3-Une proposition visant à préparer l’interdiction du chargement dynamique des agents appelle à émettre des avertissements lorsque les agents sont chargés dynamiquement dans une JVM en cours d’exécution. Ces avertissements sont destinés à préparer une future version qui interdirait le chargement dynamique des agents par défaut, afin d’améliorer l’intégrité par défaut. Les autres objectifs de la proposition incluent la réévaluation de l’équilibre entre la facilité d’entretien, qui implique des modifications ponctuelles du code en cours d’exécution, et l’intégrité, qui suppose que le code en cours d’exécution n’est pas modifié de manière arbitraire, et la garantie que la majorité des outils, qui n’ont pas besoin de charger les agents de manière dynamique, ne sont pas affectés. Le plan prévoit également d’aligner la capacité de charger des agents de manière dynamique avec d’autres capacités dites de « superpuissance » telles que la réflexion approfondie. Un agent est un composant qui peut modifier le code d’une application pendant son exécution. ceux-ci ont été introduits par l’architecture de profilage de plate-forme Java dans JDK 5 en 2004 comme moyen pour les outils (notamment les profileurs) d’accéder aux classes d’instruments. Alors que les agents ont été conçus avec une instrumentation inoffensive à l’esprit, les développeurs avancés ont découvert des cas d’utilisation, tels que la programmation orientée aspect, qui modifient le comportement des applications de manière arbitraire. Rien n’empêche non plus un agent de modifier le code en dehors de l’application, comme le code dans le JDK lui-même. JDK 5 exigeait que les agents soient spécifiés sur la ligne de commande, afin de garantir que le propriétaire d’une application approuvait l’utilisation des agents. Avec JDK 21, il est prévu d’exiger que le chargement dynamique des agents soit approuvé par le propriétaire de l’application, tout comme cela a été requis pour le chargement des agents au démarrage. Ce changement rapprochera la plate-forme Java de l’intégrité par défaut.
4-Une API pour les mécanismes d’encapsulation de clés, une technique de chiffrement pour sécuriser les clés symétriques via la cryptographie publique. L’un des objectifs de la proposition est de permettre aux applications d’utiliser des algorithmes KEM tels que le mécanisme d’encapsulation de clé RSA (RSA-KEM), le système de chiffrement intégré à courbe elliptique (ECIES) et des algorithmes candidats pour le National Institute of Standards and Technology (NIST). Processus de normalisation de la cryptographie post-quantique. Un autre objectif est de permettre l’utilisation de KEM dans des protocoles de niveau supérieur tels que Transport Layer Security (TLS) et dans des schémas cryptographiques tels que Hybrid Public Key Encryption (HPKE). Les fournisseurs de sécurité seraient en mesure d’implémenter les algorithmes KEM en code Java ou en code natif, et d’inclure une implémentation du Diffie-Hellman KEM (DHKEM) défini dans la RFC 9180.
5-Obsolescence du port Windows 32 bits x86 pour suppression, dans le but de supprimer le port dans une prochaine version. La proposition vise à mettre à jour le système de build pour émettre un message d’erreur lorsqu’une tentative de configuration d’une build pour Windows 32 bits x86 est effectuée. Le message sera supprimable via une nouvelle option de configuration. En outre, il est prévu de marquer le port et les fonctionnalités spécifiques au port associées comme obsolètes pour suppression dans la documentation pertinente. La proposition indique que Windows 10, le dernier système d’exploitation Windows à prendre en charge le fonctionnement 32 bits, arrivera en fin de vie en octobre 2025.
6-Un aperçu des classes sans nom et des méthodes principales des instances, pour faire évoluer le langage Java 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 pourraient rédiger des déclarations simplifiées pour des programmes à classe unique, puis développer de manière transparente les programmes pour utiliser des fonctionnalités plus avancées à mesure que leurs compétences se développent. La proposition offrirait non seulement une transition fluide vers Java, mais réduirait également la cérémonie impliquée dans l’écriture de programmes Java simples tels que des scripts et des utilitaires de ligne de commande.
7-Un aperçu des modèles et des variables sans nom. Les modèles sans nom correspondent à un composant d’enregistrement sans indiquer le nom ou le type du composant, tandis que les variables sans nom peuvent être initialisées mais non utilisées. Les deux sont désignés par un caractère de soulignement. Cette proposition vise à améliorer la lisibilité des modèles d’enregistrement en éliminant 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.
8-ZGC générationnel est destiné à améliorer les performances des applications en étendant ZGC pour maintenir des générations distinctes pour les objets jeunes et anciens. Les jeunes objets ont tendance à mourir jeunes ; le maintien de générations séparées permettra à ZGC de collecter plus fréquemment de jeunes objets. Les applications exécutées avec ZGC générationnel devraient bénéficier des avantages suivants : moins de risques de blocage d’allocation, moins de surcharge de mémoire requise et moins de surcharge du processeur de ramasse-miettes. Ces avantages devraient être réalisables sans réduction significative du débit par rapport au ZGC non générationnel.
9-Les modèles d’enregistrement, prévisualisés dans JDK 19 et JDK 20, déconstruiraient les valeurs d’enregistrement. 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 classes d’enregistrement et l’ajout de modèles imbriqués, permettant des requêtes de données plus composables. Cette fonctionnalité a co-évolué avec la correspondance de modèles pour les expressions et instructions switch (voir ci-dessous). La proposition de modèles d’enregistrement dans le JEP actuel (JDK Enhancement Proposal) finaliserait la fonctionnalité avec des améliorations supplémentaires basées sur l’expérience et les commentaires continus. Hormis des modifications éditoriales mineures, le principal changement depuis le deuxième aperçu est la suppression de la prise en charge des modèles d’enregistrement apparaissant dans l’en-tête d’une instruction for améliorée. La fonctionnalité pourrait être reproposée dans une future JEP.
10-La correspondance de modèles pour switch permet de tester une expression ou une instruction switch par rapport à un certain nombre de modèles, chacun avec une action spécifique, afin que des 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 le JDK 17, puis affinée dans les JDK 18, JDK 19 et JDK 20. Elle sera finalisée dans le 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 des expressions et des instructions switch. Les objectifs incluent l’expansion de l’expressivité et de l’applicabilité des expressions et des instructions switch en permettant aux modèles d’apparaître dans les étiquettes de cas, en permettant à l’hostilité nulle historique de switch d’être relâchée lorsque vous le souhaitez, et en augmentant la sécurité des instructions switch en exigeant que les instructions switch de modèle couvrent tout. valeurs d’entrée potentielles. Un autre objectif est de garantir que les expressions et instructions switch existantes continuent à être compilées sans modification et à s’exécuter avec une sémantique identique.
11-Un sixième incubateur d’API vectorielle. Cette API exprime des calculs vectoriels qui se compilent de manière fiable selon des instructions vectorielles optimales sur les architectures de processeur prises en charge, obtenant ainsi des performances supérieures aux calculs scalaires équivalents. L’API vectorielle était auparavant incubée dans le JDK 16 jusqu’au JDK 20. Cette dernière incarnation inclut des améliorations de performances et des corrections de bugs. Les objectifs de la proposition incluent d’être clair et concis, d’être indépendant de la plate-forme et d’offrir une compilation et des performances d’exécution fiables sur les architectures x64 et AArch64. D’autres objectifs incluent une dégradation gracieuse lorsqu’un calcul vectoriel ne peut pas être entièrement exprimé sous la forme d’une séquence d’instructions vectorielles.
12-Un troisième aperçu d’une API de fonction et de mémoire étrangère, qui permet aux programmes Java d’interagir avec du code et des données en dehors du runtime Java. En appelant efficacement des fonctions étrangères et en accédant en toute sécurité à la mémoire étrangère, cette API permet aux programmes Java d’appeler des bibliothèques natives et de traiter des données natives sans la fragilité et le danger de JNI (Java Native Interface). L’API était auparavant prévisualisée dans JDK 20 et JDK 19. Les améliorations apportées à l’aperçu du JDK 21 incluent des chemins de présentation améliorés avec un nouvel élément pour déréférencer les présentations d’adresses, une gestion centralisée de la durée de vie des segments natifs dans l’interface Arena, une implémentation de secours de l’éditeur de liens natif, et suppression de la 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 le JNI au-dessus de cette API, ni de la modifier de quelque manière que ce soit.
13-Les threads virtuels sont des threads légers qui promettent de réduire considérablement les efforts d’écriture, de maintenance et d’observation des applications simultanées à haut débit. Les objectifs du plan incluent la possibilité pour les applications serveur écrites dans le style simple thread par requête d’évoluer avec une utilisation matérielle presque optimale, de permettre au code existant qui utilise l’API lang.Thread d’adopter des threads virtuels avec des modifications minimes et de permettre un débogage et un débogage faciles. profilage des threads virtuels avec les outils JDK actuels. Précédemment prévisualisés dans JDK 20 et JDK 19, les threads virtuels seront finalisés dans JDK 21. Avec cette dernière, les threads virtuels prennent désormais en charge à tout moment les variables locales des threads et rendent impossible la création de threads virtuels qui n’ont pas ces variables. . La prise en charge garantie des variables locales des threads garantit que davantage de bibliothèques existantes peuvent être utilisées sans modification des threads virtuels et facilite la migration du code orienté tâche.
14-La proposition de collections séquencées introduit des interfaces pour représenter les collections avec un ordre de rencontre défini. Chaque collection comporte 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 les premier et dernier éléments et traiter les éléments dans l’ordre inverse. La proposition est motivée par une situation dans laquelle le cadre de collections de Java ne dispose pas d’un type de collection pour représenter une séquence d’éléments avec un ordre de rencontre défini. Il lui manque également un ensemble uniforme d’opérations applicables à l’ensemble de ces collections. Ces lacunes constituent un problème et une source de plaintes. La proposition appelle à définir des interfaces pour séquencer les collections, les ensembles et les cartes, et à adapter ces interfaces dans la hiérarchie des types de collections existante. Toutes ces nouvelles méthodes ont des implémentations par défaut.
15-Les modèles de chaînes, une fonctionnalité d’aperçu du JDK 21, complètent les littéraux de chaîne et les blocs de texte existants de Java en couplant le texte littéral avec des expressions et des processeurs intégrés pour produire des résultats spécialisés. Cette fonctionnalité du langage et cette API visent à 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é des programmes, de conserver la flexibilité et de simplifier l’utilisation des API acceptant les chaînes écrites dans des langages non Java. Permettre le développement d’expressions non-chaînes dérivées de la combinaison de texte littéral et d’expressions incorporées.
