Quatre fonctionnalités ont été officiellement proposées pour le kit de développement JDK 19 prévu pour septembre prochain. Deux ajouts récents, les threads virtuels et le filtrage par motifs (les deux en preview), viennent s’ajouter à deux fonctions déjà officialisées, à savoir une API vectorielle (dans sa quatrième incubation) et un portage du JDK sur l'architecture de jeu d'instructions (ISA) open source Linux/RISC-V. Potentiellement, le JDK 19, désigné simplement par Java 19, pourrait accueillir un grand nombre de fonctionnalités, depuis les génériques universels jusqu’aux Value Objects, selon les projets d’amélioration de Java en cours.

Selon le calendrier officiel de sortie du JDK 19 publié par les développeurs d'OpenJDK, la version de production de Java 19 est prévue le 20 septembre. Cette version sera précédée par des phases de rampdown le 9 juin et le 21 juillet, et des versions candidates seront publiées les 11 et 25 août. Le JDK 19 prendra la suite du JDK 18 arrivé le 22 mars, une nouvelle version de Java standard étant publiée tous les six mois. Les versions d'accès anticipé du JDK 19 sont accessibles sur jdk.java.net/19.

Des fonctions variées pour JDK 19

Parmi les fonctions, on retrouve un aperçu des threads virtuels : il s’agit de threads légers qui simplifient considérablement le travail d'écriture, de maintenance et d'observation des applications concurrentes à haut débit. Ils doivent permettre aux applications de serveur écrites dans le style simple dit de « thread par requête » d'évoluer avec une utilisation matérielle quasi-optimale ; permettre au code existant qui utilise l'API java.lang Thread d'adopter les threads virtuels avec un minimum de changements ; et permettre le dépannage, le débogage et le profilage des threads virtuels avec les outils JDK existants. L'objectif de cette proposition n'est pas de modifier le modèle de concurrence de base de Java ni de proposer une nouvelle construction de parallélisme par distribution de données dans le langage Java ou les bibliothèques Java. L'objectif n'est pas non plus de supprimer l'implémentation traditionnelle des threads ou de faire migrer silencieusement les applications existantes vers l'utilisation de threads virtuels.

Un troisième aperçu du filtrage de motifs pour les expressions et les instructions Switch fait son apparition. L'objectif ? Permettre à une expression d'être testée par rapport à un certain nombre de motifs, chacun ayant une action spécifique, de sorte que les requêtes complexes orientées données puissent être exprimées de manière concise et sûre. Cette fonctionnalité a déjà été présentée en aperçu dans les JDK 17 et JDK 18. Le troisième aperçu bénéficiera de quelques améliorations, notamment le remplacement des motifs protégés par des clauses when dans les blocs Switch. Par ailleurs, la sémantique d'exécution d'un Switch de motif, quand la valeur de l'expression de l’instruction Switch est nulle, est plus étroitement alignée sur la sémantique des instructions Switch existantes. La fonctionnalité vise notamment à étendre l'expressivité et de l'applicabilité des expressions et des instructions Switch en permettant aux motifs d'apparaître dans les étiquettes de cas, en permettant d’assouplir l'hostilité null historique de Switch à volonté, en augmentant la sécurité des instructions Switch et en garantissant que les expressions et les instructions Switch existantes continuent à compiler sans changement et à s'exécuter avec une sémantique identique.

Une quatrième incubation de l’API vectorielle arrive également. Celle-ci pourra exprimer des calculs vectoriels compilés de manière fiable au moment de l'exécution en instructions vectorielles optimales sur les architectures de CPU prises en charge. Grâce à cette API, les développeurs pourront écrire des algorithmes vectoriels complexes en Java, en utilisant l'auto-vectoriseur HotSpot, mais avec un modèle utilisateur qui rend les vectorisations plus prévisibles et plus robustes. L'API vectorielle était précédemment incubée dans les JDK 16, JDK 17 et JDK 19.

L'API vectorielle améliorée

Les améliorations de l'API proposées pour le JDK 19 ne s'arrêtent pas là et concernent le chargement et stockage des vecteurs vers et depuis des MemorySegments, comme défini par la fonction externe et l'aperçu de l'API mémoire. Le JDK 19 ajouterait également deux opérations vectorielles dites cross-lane, de compression et d’extension, ainsi qu'une opération complémentaire de compression de masque vectoriel. L'opération de compression de vecteur fait correspondre les voies d'un vecteur source, sélectionné par un masque, à un vecteur de destination dans l'ordre des voies, tandis que l'opération d'expansion fait l'inverse. L'opération de compression est utile pour filtrer les résultats des requêtes. Un autre ajout concernant l'API vectorielle comme on s'en doutait dernièrement : les opérations d'intégrale par bit à l'échelle de la voie seraient étendues, y compris les opérations comme le comptage du nombre de bits 1, l'inversion de l'ordre des bits, et la compression et l'expansion des bits. Les objectifs de l'API étaient d'être claire et concise, indépendante de la plate-forme, d'avoir des performances d'exécution et de compilation fiables sur les architectures x64 et AArch64, et de permettre une dégradation « élégante », pour les situations dans lesquelles un calcul vectoriel ne peut pas être entièrement exprimé à l'exécution en tant que séquence d'opérations vectorielles.

De plus le portage Linux/RISC-V, Java gagnerait la prise en charge d'un jeu d'instructions matérielles déjà supporté par de nombreuses chaînes d'outils de langage. RISC-V est en fait une famille d'ISA associée. Le portage Linux/RISC-V ne supporterait que la configuration RV64GV de RISC-V, un ISA 64 bits à usage général qui inclut des instructions vectorielles. Les développeurs de Java pourraient envisager d'autres configurations RISC-V à l'avenir. Le portage prendrait en charge les options HotSpot VM suivantes : l'interpréteur de modèle, le compilateur JIT C1 (client), le compilateur JIT C2 (serveur) et tous les ramasse-miettes actuels, y compris ZGC et Shenandoah. Le portage proprement dit est presque terminé ; l'objectif de la proposition d'amélioration du JDK (JEP) est d’intégrer le portage dans le référentiel principal du JDK. Outre le portage RISC-V et l'API vectorielle, un aperçu de la fonction externe et de l'API mémoire, permettant aux programmes Java d'interagir avec du code et des données en dehors du runtime JVM, semble également destiné à être officiellement ciblé sur le JDK 19, puisque la proposition d'API elle-même cite le JDK 19 comme destination. Comme le JDK 18, le JDK 19 sera une version à court terme, assortie de six mois de support Premier de haut niveau seulement. La version précédente, JDK 17, était une version Long Term Support (LTS), qui offrait plusieurs années de support. Cette dernière version LTS a été livrée le 14 septembre 2021.