Sortie en mars, la mise à niveau du kit de développement Java prend en charge les fonctionnalités du langage C++ 14 dans le code source C++ du JDK et de la VM HotSpot. Cette version printanière va-t-elle tout bouleverser ou ne sera-t-elle qu’annonciatrice de nouveautés intéressantes ? C’est ce que nous allons tenter de voir dans cet article.
Le JDK 16 (Java Development Kit) est une version à court terme – non LTS – qui ne sera prise en charge que pendant six mois. Ses nouvelles fonctionnalités incluent de nouvelles API et de nouveaux outils, une encapsulation plus forte de ses composants internes, plusieurs portages vers des systèmes d’exploitation, l’activation des fonctionnalités du langage C++ 14 dans le code source, une API vectorielle, la migration de Mercurial à Git et la migration vers GitHub. De nouvelles API et de nouveaux outils sont encore en incubation et ne sont pas livrées intégralement dans la version 16.
En voici une liste non exhaustive :
•API Vector (en incubation)
•API Foreign Linker (en incubation)
•API Foreign-Memory Access (troisième incubation, le bout du tunnel se rapproche)
•Unix-Domain Socket Channels (canaux de communication via des sockets réseau de type domaine Unix)
•Outil de Packaging
Les trois premières API sont issues du Projet Panama (https://openjdk. java.net/projects/panama/), projet OpenJDK visant à améliorer la capacité du code géré par la JVM à interagir avec des API «étrangères» (non Java). Cela inclut particulièrement les interfaces couramment utilisées par les bibliothèques C. Le projet Panama peut être vaguement considéré comme un nouveau JNI (Java Native Interface), mais en bien plus riche. Quelques améliorations mineures ont été apportées à la machine virtuelle, notamment via Elastic Metaspace et ZGC (traitement parallélisé des piles de threads pour le nettoyage de la mémoire).
Le premier, Elastic Metaspace, permet à la JVM de libérer plus rapidement la mémoire inutilisée de la zone de métadonnées internes vers le système d’exploitation. Le second est une amélioration des performances du ramasse-miettes ZGC (Z Garbage Collector). Les objectifs de ce projet sont d’accélérer les traitements en les parallélisant au maximum.
De nouveaux portages d’OpenJDK vers différents systèmes d’exploitation sont aussi attendus. Parmi eux, l’un des plus intéressants est sans doute le portage du JDK pour Alpine Linux et d’autres distributions Linux utilisant musl comme bibliothèque C de base sur des architectures x64 et AArch64. Musl est une implémentation Linux des fonctionnalités de la bibliothèque standard décrites dans les standards ISO C et Posix. Alpine Linux est largement utilisée dans les déploiements cloud, les microservices et les environnements à base de containers en raison surtout de la petite taille de son fichier d’images. Pour vous faire une idée, une image Docker pour Alpine Linux fait moins de 6 Mo. Le fait que le Java puisse être exécuté dans de tels environnements spécifiques va permettre à Tomcat, Jetty, Spring et autres frameworks populaires de fonctionner nativement dans ces environnements. Un utilisateur peut même créer une image plus petite «taillée» pour exécuter une application particulière en ayant recours à jlink (https://openjdk.java.net/jeps/282) afin de réduire la taille de la JVM. Le portage de port MacOS / AArch64 permettra quant à lui d’utiliser le Java sur la nouvelle architecture Silicon d’Apple. Il bénéficie du soutien technique conjugué d’Azul Systems et de Microsoft, ce qui n’est pas rien. Parmi les fonctionnalités du projet Amber (https://openjdk. java.net/projects/amber/) un autre projet participant à la refonte et à l’évolution du langage Java, les principales sont sans doute le Pattern Matching pour instanceof, les Records et les Sealed Classes – les classes «finales», c’est-à-dire non dérivables. Une autre fonctionnalité destinée aux développeurs est la Strongly Encapsulate JDK Internals by Default. C’est en fait la prochaine étape d’un processus visant à fermer l’accès aux composants internes du JDK dans le but d’accélérer le travail de l’équipe de développement d’OpenJDK.
Cela n’inclut pas la fameuse classe sun.misc.Unsafe, qui restera disponible pour des raisons de rétrocompatibilité mais a été déplacée vers le module jdk.unsupported. A priori, ni le projet Valhalla (https://openjdk. java.net/projects/valhalla/) ni le projet Loom (https://openjdk.java.net/ projects/loom/) ne seront livrés en preview d’ici à mars prochain. Il faudra attendre encore un peu, sans doute jusqu’à la version 18 ou 19.
Le projet Valhalla concerne l’ajout des inline types et la refonte du modèle de données bas niveau de la JVM. Le projet Loom porte quant à lui sur l’ajout de «threads virtuels» gérés par la JVM et sur un modèle de concurrence considérablement accrue.
En résumé, aucun des quatre grands projets en cours dans OpenJDK que sont Amber, Loom, Panama et Valhalla ne sera complètement livrable même dans la version 17 prévue pour septembre. Concernant Amber, les records et les classes « sealed » devraient être prêts, mais la partie Pattern Matching restera sans doute très incomplète. Certaines des JEP de Panama (la JEP 393, qui en est à la 3e incubation dans Java 16) peuvent également être finalisés, mais pas toutes évidemment. Rappelons que le JEP (JDK Enhancement Proposal, proposition d’amélioration du JDK) est un processus élaboré par Oracle Corporation pour collecter des propositions d’amélioration du kit de développement Java et d’OpenJDK. Le JEP sert de feuille de route à long terme pour les projets de publication JDK. Concrètement, très peu d’équipes de développement sont prêtes à adopter la cadence de mise à jour forcée semestrielle des versions de Java imposée par Oracle. Jusqu’à maintenant, la plupart continuent à utiliser le Java 8 ou Java 11, quand bien même cela signifie abandonner Oracle en tant que fournisseur java. Les atermoiements de l’éditeur n’ont fait que confirmer cette tendance et il y a peu de chances que cela change en 2021.
Les nouveautés, en résumé
Parmi les fonctionnalités d’ores et déjà annoncées, voici les principales : L’activation des fonctionnalités du langage C++ 14 afin de permettre l’utilisation des fonctionnalités du langage C++ 14 dans le code source C++ du JDK et de fournir des indications spécifiques sur les fonctionnalités pouvant être utilisées dans le code de la VM HotSpot. Jusqu’au JDK 15, les fonctionnalités de langage utilisées par le code C++ dans le JDK étaient limitées aux normes du langage C++98/03. Le code source a été mis à jour à partir du JDK 11 en vue de supporter des versions plus récentes du code C++ standard.
Une API vectorielle, en phase de test, dans laquelle le JDK sera équipé d’un module d’incubation, jdk.incubator. vector, pour exprimer des calculs vectoriels qui compilent de manière optimale les instructions matérielles vectorielles (sur les architectures CPU supportées, x64 et AArch64), afin d’obtenir des performances supérieures à celles des calculs scalaires équivalents. Cette API vectorielle est censée apporter un mécanisme d’écriture des algorithmes vectoriels complexes en Java. Elle utilise à cette fin le support préexistant dans la VM HotSpot pour la vectorisation, mais avec un modèle utilisateur qui rend cette vectorisation plus précise et plus robuste. Les objectifs de cette fonctionnalité sont de fournir une API claire et concise pour exprimer une série de calculs vectoriels, d’être indépendant de la plate-forme en prenant en charge plusieurs architectures de CPU et d’offrir une compilation et des performances d’exécution fiables. La dégradation progressive fait également partie des objectifs. Elle implique qu’un calcul vectoriel peut se dégrader progressivement et continuer à fonctionner s’il ne peut pas être entièrement exprimé en cours d’exécution sous la forme d’une séquence d’instructions vectorielles matérielles. Cela peut arriver soit parce qu’une architecture CPU ne prend pas en charge certaines instructions, soit tout simplement parce qu’une architecture n’est pas prise en charge.
La migration des référentiels de code source OpenJDK de Mercurial vers Git présente plusieurs avantages : la réduction de la taille des métadonnées du système de contrôle de version et l’accès à de nombreux outils importants et à des options d’hébergement. La migration vers GitHub, liée bien évidemment à la migration de Mercurial vers Git, est aussi importante. Les référentiels de code source du JDK 16 seront mis à disposition sur GitHub.
Une étape de plus vers les types valeurs a été réalisée. Les types classes wrappers représentant les types primitifs sont considérés comme des types valeurs et leurs constructeurs sont dépréciés. Il sera possible de transformer des fichiers de code source en images Docker sans fichiers Docker avec les bénéfices supplémentaires des fichiers Jars en couches.
Les versions préliminaires du JDK 16 pour Linux, Windows et MacOS sont disponibles à l’adresse https://jdk.java. net/16/. Comme le JDK 15, le JDK 16 sera une version à court terme, c’est-à-dire avec une prise en charge de seulement six mois. Le JDK 17, prévu pour septembre 2021, devrait être une version de support à long terme (LTS). La version LTS actuelle, la JDK 11, était sortie en septembre 2018.
Le projet Panama
Parmi les différents projets en cours de l’OpenJDK, Panama (https:// openjdk.java.net/projects/panama/) est sans doute l’un des plus intéressants. Son but est l’interconnexion entre la JVM et le code natif. Il vise à améliorer les interactions entre le code géré par la JVM et des API non Java comme, notamment, les interfaces couramment utilisées par les bibliothèques C. Pour y arriver, le projet Panama inclura de nombreux composants tels que l’appel de fonctions natives depuis la JVM, un accès aux données natif depuis la JVM ou même la partie tas (heap) de la mémoire de la JVM, de nouvelles couches de données dans le heap de la JVM, la définition de métadonnées toujours en natif pour la JVM, des outils d’extraction de fichier d’en-tête d’API (jextract), des API de gestion de bibliothèque de code natif, des optimisations du compilateur JiT (Just in Time, « à la volée») orientées code natif, une sécurité accrue des appels de code natif et un travail d’exploration sur les bibliothèques de code natif difficiles à intégrer. Ce projet soutenu par le Hotspot Group concerne les JEP 370 et 383 pour les API d’accès à la mémoire du code «étranger », la 389 pour l’API de liaison (édition de liens) «étrangère» et la JEP 338 pour l’API vectorielle.
Version LTS ou non
Le Java 16 n'est pas une version de support à long terme (LTS), il est donc peu probable qu’il soit adopté à grande échelle. La prochaine version LTS devrait être la 17, du moins si la feuille de route actuelle est respectée. Elle est planifiée pour septembre 2021 (6 mois après la 16). Aucune fonctionnalité spécifique n’a encore été annoncée pour cette version. Néanmoins, les fonctionnalités de la version 16 seront reprises pour la plupart dans Java 17. Le principe est de «tester » dans la 16 ou plutôt de commencer à implémenter les nouveautés qui seront totalement intégrées dans la version 17. Oracle ne fournit généralement pas de nouvelles fonctionnalités majeures sans au moins un cycle de preview. C’est la tradition. Et c’est aussi une très bonne habitude en matière d’intégration continue.