1. Introduction
Java 21 entre dans la phase de version candidate, qui comprend 15 fonctionnalités finales, notamment des threads virtuels, un garbage collector Z générationnel et une API de mécanisme d'encapsulation de clés.
JDK21 devrait être publié le 19 septembre en tant que prochaine version LTS de l'implémentation Java standard d'Oracle et est entré dans la phase Release Candidate (RC). Java 21 comportera 15 nouvelles fonctionnalités, la 16e précédemment proposée, le garbage collector expérimental Shenandoah, abandonnée en juin.
Les 15 fonctionnalités entrant dans la version finale vont des modèles de chaînes et des aperçus de concurrence structurée, aux threads virtuels et à l'API Key Encapsulation Mechanism (KEM). JDK 21 est entré dans la deuxième phase de développement incrémental le 20 juillet, après le premier développement incrémental le 8 juin. La phase Release Candidate commence le 10 août, en même temps que la phase 2 de développement incrémentiel. La sortie du deuxième RC est prévue pour le 24 août. Oracle publie une nouvelle version de Java standard tous les 6 mois, la dernière en date étant le JDK 20 le 21 mars 2022.
2 Propositions spécifiques pour JDK 21
2.1 Concurrence structurée (aperçu)
La programmation simultanée est simplifiée grâce à l'API de concurrence structurée, qui traite les groupes de tâches connexes exécutées dans différents threads comme une unité de travail. Cela simplifie la gestion et l’annulation des erreurs, améliore la fiabilité et améliore l’observabilité.
La concurrence structurée est incubée dans JDK 20 et JDK 19 (publiés en mars et septembre 2022) ; elle apparaîtra dans le package JUC en tant qu'API en avant-première. Le seul changement notable cette fois est que la méthode StructuredTaskScope::Fork(…) renvoie une [Sous-tâche] au lieu d'un Future.
Les objectifs de la concurrence structurée incluent la promotion d'un style de programmation concurrente qui élimine les risques courants d'annulation et d'arrêt, tels que les fuites de threads et les retards d'annulation, et l'amélioration de l'observabilité du code concurrent.
2.2 Valeur du périmètre
Également en avant-première, permettra le partage de données immuables à l'intérieur et à l'extérieur des threads. Elles sont préférées aux variables locales de thread, 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, des durées de vie illimitées et un héritage coûteux. Les valeurs étendues permettent aux composants d'un grand programme de partager des données en toute sécurité sans utiliser de paramètres de méthode. Cette proposition a été incubée dans JDK 20. Les objectifs du programme incluent la facilité d'utilisation, la compréhensibilité, la robustesse et les performances.
2.3 Interdire le chargement dynamique du proxy
Une proposition visant à interdire les proxys chargés dynamiquement nécessite un avertissement lors du chargement dynamique de proxys sur une JVM en cours d'exécution. Ces avertissements sont destinés à préparer une future version visant à désactiver le chargement dynamique des proxys par défaut, par souci d'exhaustivité. Les autres objectifs de la proposition comprennent la réévaluation :
- Maintenabilité (implique des modifications spéciales du code en cours d'exécution)
- Intégrité (en supposant que le code en cours d'exécution ne change pas arbitrairement)
et assurez-vous que la plupart des outils qui ne nécessitent pas de proxys chargés dynamiquement ne sont pas affectés. Le plan prévoit également d'aligner la capacité de charger dynamiquement des proxys avec des fonctionnalités de « superpuissance » telles que la réflexion profonde. Un proxy est un composant qui modifie le code d'une application pendant son exécution. Ces composants ont été introduits par l'architecture de profilage de plate-forme Java dans JDK 5 en 2004 comme moyen de permettre aux outils (en particulier aux profileurs) d'instrumenter les classes. Bien que l'agent soit conçu pour une détection inoffensive, les développeurs avancés ont trouvé des cas d'utilisation tels que la programmation orientée aspect pour modifier le comportement des applications de manière arbitraire. Encore une fois, rien n'empêche le proxy de modifier le code tel que le JDK lui-même. JDK 5 nécessite que les proxys soient spécifiés sur la ligne de commande pour garantir que le propriétaire de l'application approuve l'utilisation des proxys. Dans le JDK 21, il est prévu d'exiger l'approbation du propriétaire de l'application pour charger les proxys de manière dynamique, tout comme le chargement des proxys au démarrage. Ce changement rapproche la plate-forme Java de l'exhaustivité par défaut.
2.4 API du mécanisme d'encapsulation des clés
Technique de chiffrement qui encapsule de manière sécurisée une clé symétrique via une cryptographie à clé publique. L'un des objectifs de la proposition est de permettre aux applications d'utiliser :
- Mécanisme d'encapsulation de clé RSA (RSA-KEM)
- Schéma de chiffrement intégré à courbe elliptique (ECIES) et autres algorithmes KEM
- et algorithmes candidats pour le processus de normalisation de la cryptographie post-quantique du National Institute of Standards and Technology (NIST)
Un autre objectif est de pouvoir utiliser KEM dans des protocoles de niveau supérieur (tels que Transport Layer Security Protocol TLS) et des schémas cryptographiques (tels que Hybrid Public Key Encryption HPKE). Les fournisseurs de sécurité peuvent implémenter l'algorithme KEM en Java ou en code natif, et inclure une implémentation de Diffie-Hellman KEM (DHKEM) telle que définie dans la RFC 9180.
2.5 Port Windows 32 bits x86 obsolète
pour la suppression dans une version ultérieure, l'intention est de supprimer le port dans une version ultérieure. Cette proposition vise à mettre à jour le système de build pour émettre un message d'erreur lors de la tentative de build pour la configuration Windows 32 bits x86. Les messages peuvent être supprimés via une nouvelle option de configuration. De plus, il est prévu de marquer le port et les fonctionnalités spécifiques au port associées comme obsolètes afin de supprimer la documentation associée. La proposition indique que Windows 10, le dernier système d'exploitation Windows à prendre en charge les opérations 32 bits, terminera son cycle de vie en octobre 2025.
2.6 Aperçu de la méthode principale de classe et d'instance sans nom
Il est destiné à faire évoluer le langage Java afin que les étudiants puissent écrire leurs premiers programmes Java sans comprendre les fonctionnalités du langage pour la programmation à grande échelle. Au lieu d'utiliser des dialectes Java distincts, les étudiants peuvent rédiger des déclarations simplifiées pour des programmes à classe unique, puis étendre les programmes de manière transparente pour utiliser des fonctionnalités plus avancées. La proposition fournirait non seulement une introduction fluide à Java, mais réduirait également les tracas liés à l'écriture de programmes Java simples tels que des scripts et des utilitaires de ligne de commande.
2.7 Aperçu des modèles et variables sans nom
Les modèles sans nom correspondent aux composants d'enregistrement sans déclarer le nom ou le type du composant, et les variables sans nom peuvent être initialisées mais pas utilisées. Les deux sont désignés par le caractère de soulignement _. La proposition vise à améliorer la lisibilité des schémas documentés en omettant les schémas 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.
2.8 ZGC générationnel
Conçu pour améliorer les performances des applications en maintenant des générations distinctes pour les objets jeunes et anciens. Les jeunes objets ont tendance à mourir rapidement ; le maintien d’une génération distincte permettra à ZGC de collecter de jeunes objets plus fréquemment. Les applications exécutées sur ZGC générationnel devraient bénéficier des avantages suivants : un risque moindre d'interruptions d'allocation, une surcharge de mémoire tas requise inférieure et une surcharge CPU inférieure pour le garbage collection. Ces avantages devraient être réalisables sans baisse significative du débit.
2.9 Mode d'enregistrement
Prévisualisé dans JDK 19 et JDK 20 pour la déstructuration des valeurs d'enregistrement. Les schémas d'enregistrement et les schémas de type peuvent être imbriqués pour permettre des formes puissantes, déclaratives et composables de navigation et de manipulation de 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, l'ajout de modèles imbriqués pour permettre 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). Le JEP actuel finalisera cette fonctionnalité en l’affinant davantage sur la base de l’expérience et des commentaires continus. Le changement majeur, mis à part des modifications éditoriales mineures, est la suppression de la prise en charge des modèles d'enregistrement apparaissant dans l'en-tête de la déclaration for améliorée. Cette fonctionnalité pourrait être réintroduite dans une future JEP.
2.10 Correspondance de modèle du commutateur
Cela permet de tester des expressions ou des instructions de commutation par rapport à de nombreux modes, chacun avec des opérations spécifiques, afin que les requêtes de données complexes puissent être exprimées de manière sûre et concise. Cette fonctionnalité a été proposée pour la première fois dans le JDK 17 et a depuis été affinée dans le JDK 18, le JDK 19 et le JDK 20. Il sera finalisé dans le JDK 21 avec d'autres optimisations. Le principal changement par rapport au JEP précédent est la suppression des modèles entre parenthèses et l'autorisation des constantes d'énumération qualifiées, telles que celles avec des expressions et des instructions switch. Les objectifs incluent l'extension du pouvoir expressif et de l'applicabilité des expressions et 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 en cas de besoin et en augmentant la sécurité de l'instruction switch. Un autre objectif est de garantir que les expressions et instructions switch existantes continuent à être compilées sans modification et à avoir la même sémantique.
2.11 Le sixième incubateur d'API vectorielles
Cette API exprime des calculs vectoriels qui se compilent de manière fiable en instructions vectorielles optimisées sur les architectures de processeur prises en charge, surpassant ainsi les calculs scalaires équivalents. L’API vectorielle a été précédemment incubée du JDK 16 au JDK 20. Cette dernière version inclut des améliorations de performances et des corrections de bugs. Les objectifs de la proposition incluent la clarté et la simplicité, l'indépendance de la plate-forme, ainsi qu'une compilation et des performances d'exécution fiables sur les architectures x64 et AArch64. D'autres objectifs incluent une dégradation gracieuse lorsque les calculs vectoriels ne peuvent pas être entièrement représentés sous forme de séquences d'instructions vectorielles.
2.12 Troisième aperçu des fonctions étrangères et de l'API mémoire
Il permet aux programmes Java d'interagir avec du code et des données en dehors du runtime Java. En appelant efficacement des fonctions externes et en accédant en toute sécurité à la mémoire externe, cette API permet aux programmes Java d'appeler des bibliothèques natives et de manipuler des données natives sans la fragilité et le danger liés à l'utilisation de JNI (Java Native Interface). L'API a déjà été prévisualisée dans JDK 20 et JDK 19. Les améliorations apportées à l'aperçu du JDK 21 incluent des chemins de mise en page améliorés avec de nouveaux éléments pour déréférencer les mises en page d'adresses, une gestion centralisée des cycles de vie des segments natifs dans l'interface Arena, des implémentations alternatives d'éditeurs de liens natifs et la suppression de VaList. Les objectifs de la proposition incluent la facilité d'utilisation, les performances, la généralité et la sécurité. Son objectif n'est pas de réimplémenter JNI par-dessus cette API, ni de modifier JNI d'une manière ou d'une autre.
2.13 Fils virtuels
sont des threads légers qui promettent de réduire considérablement l'effort d'écriture, de maintenance et d'observation des applications simultanées à haut débit. Les objectifs de cette initiative incluent la possibilité pour les applications serveur écrites dans le style de requête threadée d'évoluer avec une utilisation matérielle presque optimale, de permettre au code existant utilisant l'API lang.Thread d'adopter des threads virtuels avec des modifications minimes et d'utiliser les outils JDK actuels Déboguer et profiler facilement fils virtuels. Les threads virtuels ont été prévisualisés dans JDK 20 et JDK 19 et seront finalisés dans JDK 21. Dans JDK 21, les threads virtuels prennent désormais toujours en charge les variables locales des threads et rendent impossible la création de threads virtuels qui n'en ont pas. Garantir la prise en charge des variables locales des threads garantit qu'un plus grand nombre de bibliothèques existantes peuvent être utilisées sans modification avec les threads virtuels et permet de migrer le code orienté tâche pour utiliser les threads virtuels.
2.14 Collections de séquences
La proposition introduit une interface représentant une collection avec un ordre de rencontre défini. Chaque collection a des premier et deuxième éléments bien définis, etc. jusqu'au dernier élément. Une API uniforme est fournie pour accepter les premier et dernier éléments et les éléments de processus dans l'ordre inverse. La motivation de cette proposition est que le framework de collections Java ne dispose pas d'un type de collection qui représente une séquence d'éléments avec un ordre de rencontre défini. Il lui manque également un ensemble unifié d’opérations applicables à ces collections. Ces défauts ont été une source constante de questions et de plaintes. La proposition appelle à définir des interfaces pour les collections de séquences, les collections 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.
2.15 Modèles de chaînes
Une fonctionnalité d'aperçu du JDK 21 qui complète les blocs littéraux de chaîne existants de Java en combinant du texte littéral avec des expressions et des processeurs intégrés pour produire des résultats spécifiques. Cette fonctionnalité du langage et cette API visent à simplifier l'écriture de programmes Java en facilitant la représentation de chaînes pour les valeurs calculées dynamiquement. Il promet d'améliorer la lisibilité des expressions, d'améliorer la sécurité des programmes, de maintenir la flexibilité et de simplifier les API permettant de travailler avec des chaînes écrites dans des langages autres que Java. Permettre le développement de la dérivation d'expressions non-chaînes à partir de combinaisons de texte littéral et d'expressions incorporées est également un objectif.
Indépendamment de ces propositions d'amélioration du JDK, selon l'équipe Java d'Oracle, le JDK 21 modifiera la façon dont le JDK attribue des noms aux interfaces réseau sous Windows. Les responsables d'applications qui effectuent la multidiffusion réseau ou utilisent l'API java.net.NetworkInterface doivent être conscients de ce changement.
Le JDK a historiquement synthétisé les noms des interfaces réseau sous Windows. Cela a été modifié pour utiliser le nom attribué par le système d'exploitation Windows. Cette modification peut affecter le code qui utilise la méthode NetworkInterface.GetbyName(String name) pour rechercher une interface réseau. JDK 21 introduira également des changements clés dans l'enregistreur de vol JDK, notamment en facilitant l'analyse des enregistrements de vol à partir de la ligne de commande.
En version LTS, le JDK 21 bénéficiera de 5 ans de support principal et d'un support étendu jusqu'en septembre 2031. La version LTS actuelle est le JDK 17, qui sortira en septembre 2021. Les versions non LTS telles que JDK 20 et JDK 19 ne reçoivent que 6 mois de support principal et aucun support étendu. Les versions LTS sont publiées tous les deux ans.
référence
- https://openjdk.org/projects/jdk/21/
référence