Le JDK 19, la seconde version non-LTS depuis le JDK 17, a atteint sa phase initiale de release candidate comme déclaré par Mark Reinhold, architecte en chef, Java Platform Group chez Oracle. Le référentiel de source principal, dérivé du référentiel de stabilisation du JDK de début juin 2022 (Rampdown Phase One), définit l'ensemble de fonctionnalités pour le JDK 19. Les bugs critiques, tels que les régressions ou les problèmes de fonctionnalité graves, peuvent être résolus, mais doivent être approuvés via le processus Fix-Request. Conformément au calendrier de publication, le JDK 19 sera officiellement publié le 20 septembre 2022.
L'ensemble final de sept (7) nouvelles fonctionnalités, sous la forme de JEP, peut être séparé en trois catégories : Bibliothèque Java Core, Spécification Java et portage Hotspot
Quatre (4) de ces nouvelles fonctionnalités sont classées dans la Bibliothèque Java Core :
- JEP 424: Foreign Function & Memory API (Preview)
- JEP 425: Virtual Threads (Preview)
- JEP 426: Vector API (Quatrième Incubator)
- JEP 428: Structured Concurrency (Incubator)
Deux (2) de ces nouvelles fonctionnalités sont classées dans la spécification Java :
- JEP 405: Record Patterns (Preview)
- JEP 427: Pattern Matching for switch (troisième Preview)
Et enfin, une (1) seule fonctionnalité est classée dans le portage Hotspot :
- JEP 422 : Linux/RISC-V Port
Nous examinons ces nouvelles fonctionnalités et incluons où elles tombent sous les auspices des quatre principaux projets Java - Amber, Loom, Panama et Valhalla - conçu pour incuber une série de composants pour une éventuelle inclusion dans le JDK via une fusion organisée.
Le projet Amber
La JEP 405, Record Patterns (Preview), propose d'enrichir le langage avec des record patterns pour déconstruire les valeurs des records. Les record patterns peuvent être utilisés conjointement avec les type patterns pour "permettre une forme puissante, déclarative et composable de navigation et de traitement des données". Les type patterns ont été récemment étendus pour une utilisation dans les étiquettes de case d'un switch via la JEP 406, Pattern Matching for switch (Preview) (livrée dans le JDK 17), et la JEP 420, Pattern Matching for switch (Second Preview) (fournie dans le JDK 18). Plus de détails sur la JEP 405 peuvent être trouvés dans cette actualité d'InfoQ.
La JEP 427, Pattern Matching for switch (Third Preview), intègre des améliorations en réponse aux commentaires des deux précédents cycles de preview : la JEP 406, Pattern Matching for switch (Preview) (livrée dans le JDK 17), et la JEP 420, Pattern Matching for switch (Second Preview) (livrée dans le JDK 18). Les modifications par rapport à la JEP 420 incluent : les guarded patterns sont remplacés par des clauses when dans les blocs switch ; et la sémantique d'exécution d'un pattern dans un switch est plus étroitement alignée sur la sémantique d'un switch historique lorsque la valeur de l'expression du sélecteur est null.
Le projet Loom
La JEP 425, Virtual Threads (Preview), introduit les threads virtuels, des threads légers qui réduisent considérablement l'effort d'écriture, de maintenance et d'observation des applications concurrentes à haut débit, à la plate-forme Java. Plus de détails sur la JEP 425 peuvent être trouvés dans cette actualité d'InfoQ et cette vidéo JEP Café par José Paumard, Java developer advocate, Java Platform Group chez Oracle.
La JEP 428, Structured Concurrency (Incubator), propose de simplifier la programmation multithread en introduisant une bibliothèque pour traiter plusieurs tâches s'exécutant dans différents threads comme une seule unité de travail. Cela peut rationaliser la gestion des erreurs et l'annulation, améliorer la fiabilité et améliorer l'observabilité. De plus amples détails sur la JEP 428 peuvent être trouvés dans cette actualité d'InfoQ.
Le project Panama
La JEP 424, API Foreign Function & Memory (Preview), introduit une API permettant aux applications Java d'interagir avec le code et les données en dehors du runtime Java en invoquant efficacement des fonctions natives et en accédant en toute sécurité à la mémoire native qui n'est pas gérée par la JVM. Cette JEP évolue : la JEP 419, Foreign Function & Memory API (Second Incubator), livrée dans le JDK 18 ; et la JEP 412, Foreign Function & Memory API (Incubator), livré dans le JDK 17 ; pour intégrer des améliorations basées sur les commentaires de la communauté Java.
La JEP 426, Vector API (Fourth Incubator), intègre des améliorations en réponse aux commentaires des trois cycles d'incubation précédents : la JEP 417, Vector API (Third Incubator) (livrée dans le JDK 18), la JEP 414, Vector API (Second Incubator) (livrée dans le JDK 17), et la JEP 338, Vector API (Incubator), livrée sous la forme d'un module incubateur dans le JDK 16. La JEP 426 propose d'améliorer l'API Vector pour charger et stocker des vecteurs vers et depuis un MemorySegment tel que défini par la JEP 424, Foreign Function & Memory API (Preview).
Portage Hotspot
La JEP 422, Linux/RISC-V Port, propose de porter le JDK vers Linux/RISC-V, un jeu d'instructions open-source pour architecture RISC. L'interpréteur de template, les compilateurs JIT C1 et C2 et tous les GC principaux actuels, y compris ZGC et Shenandoah, seront pris en charge. L'objectif principal de cette JEP est d'intégrer le portage dans le référentiel principal du JDK.
JDK 20
Prévu pour une version GA en mars 2023, il n'y a pas de JEP ciblée pour le JDK 20 pour le moment. Cependant, sur la base des projets de JEP et des JEP candidates récemment soumises, nous pouvons supposer quels JEP ont le potentiel d'être incluses dans le JDK 20.
La JEP 429, Extent-Local Variables (Incubator), sous les auspices du projet Loom, propose de permettre le partage de données immuables dans et entre les threads. Cette méthode est préférable aux variables thread-local, surtout lorsqu'on utilise un grand nombre de threads virtuels. Vous trouverez plus de détails sur la JEP 429 dans cette actualité d'InfoQ.
La JEP Draft 8277163, Value Objects (Preview), une JEP sous les auspices du projet Valhalla, propose la création de value objets - des classes encapsulant des valeurs sans identité qui spécifient le comportement de leurs instances. Ce brouillon est lié à la JEP 401, Primitive Classes (Preview), qui est toujours dans le statut Candidate.
La JEP 401, Primitive Classes (Preview), également sous les auspices du projet Valhalla, introduit les classes primitives déclarées par le développeur - des types spéciaux de value classes telles que définies dans la JEP Value Objects (Preview) susmentionné - qui définissent de nouveaux types primitifs.
La JEP Draft 8273943, String Templates (Preview), une JEP qui propose d'améliorer le langage de programmation Java avec des string templates, qui sont similaires à littéraux de chaîne mais qui contiennent des expressions embarquées qui sont incorporées dans le templace de la chaîne au moment de l'exécution.
La JEP Draft 8280836, Sequenced Collections, propose d'introduire "une nouvelle famille d'interfaces qui représentent le concept d'une collection dont les éléments sont disposés en une séquence ou un ordre bien défini, en tant que propriété structurelle de la collection." Ceci est motivé par l'absence d'un ordre bien défini et d'un ensemble uniforme d'opérations dans le framework Collections.
La JEP Draft 8284289, Improved Way of Obtaining Call Traces Asynchronously for Profiling, une JEP qui propose de définir une API efficace pour obtenir des suivis d'appels asynchrones des traces d'appel pour le profilage à partir d'un gestionnaire de signal avec des informations sur des frames Java et natives.
La JEP Draft 8283227, JDK Source Structure, une JEP informative, décrit la disposition et la structure globales du code source du JDK et des fichiers associés dans le référentiel JDK. Cette JEP propose d'aider les développeurs à s'adapter à la structure du code source telle que décrite dans la JEP 201, Modular Source Code, livrée dans le JDK 9.
La JEP Draft 8280389, ClassFile API, propose de fournir une API pour analyser, générer et transformer des fichiers .class Java. Cette JEP servira initialement de remplacement interne pour ASM, le framework de manipulation et d'analyse de bytecode Java, dans le JDK avec des plans pour l'ouvrir en tant qu'API publique. Brian Goetz, architecte du langage Java chez Oracle, a qualifié ASM d'"ancienne base de code avec beaucoup de bagages hérités" et a fourni des informations générales sur la manière dont ce projet évoluera et remplacera finalement ASM.
La JEP Draft 8278252, JDK Packaging and Installation Guidelines, une JEP informative, a proposé de fournir des directives pour la création d'installateurs JDK sur macOS, Linux et Windows pour réduire les risques de collisions entre les installations du JDK par différents fournisseurs de JDK. L'intention est de promouvoir une meilleure expérience lors de l'installation des versions de mise à jour du JDK en formalisant les noms des répertoires d'installation, les noms des packages et d'autres éléments des programmes d'installation pouvant entraîner des conflits.
Nous prévoyons qu'Oracle commencera très bientôt à cibler certains d'entre eux et d'autres JEP pour le JDK 20.