JDK 22 et le ML : Oracle aimerait que Java devienne une alternative à Python
Non seulement Oracle et la communauté derrière l’OpenJDK veulent simplifier Java, mais ils souhaitent également adapter progressivement le langage aux charges de travail de machine learning. Dans un même temps, les entreprises et l’écosystème tentent de suivre le cycle de mise à jour qui commence à présenter des effets indésirables.
Oracle a annoncé la disponibilité générale du JDK 22. Cette version non-LTS, qui est au cœur de Java SE, inclut 12 fonctionnalités, dont huit en préversion ou en incubation et, comme souvent, une centaine de correctifs afin de supprimer des erreurs et des vulnérabilités.
Oracle, contributeur principal à l’OpenJDK, a décidé en 2018 d’accélérer le cycle de livraison logicielle du langage de programmation. Depuis lors, sans surprise, chaque version de JDK 10 à JDK 22 compte bien moins de fonctionnalités que JDK 9 et 8. Pour autant, JDK 22 peut être considéré comme au-dessus de la moyenne si l’on s’en tient à ce décompte de fonctionnalités. Les trois dernières versions intermédiaires (JDK 18, 19 et 20) ne cataloguaient respectivement que 9, 7 et 6 fonctionnalités. Pour rappel, la dernière version LTS en date, le JDK 21, en listait 15.
Ce décompte, somme toute futile, est la trace des différents projets en cours depuis 2019 au sein de la communauté Java. Oracle en dénombre sept majeurs : Loom, ZGC, Panama, Amber, Leyden, Valhalla et Babylon.
Loom vise une meilleure prise en charge des flux concurrents. « Loom permet de développer des services à large échelle sans goulet d’étranglement », résume Bernard Traversat, vice-président, Software Development, Java Platform Group chez Oracle.
Un ensemble d’optimisations
Dans le JDK 22, deux JEP (Java Enhancement Proposal) sont rattachés au projet Loom : JEP 462 et JEP 464.
La première proposition est une amélioration liée aux JEP 428 (JDK 19) et JEP 437 (JDK 20) pour la concurrence structurée. Celle-ci permet de traiter des groupes de tâches liées s’exécutant dans différents threads comme s’il s’agissait d’une seule charge de travail. La JEP 462 correspond à la seconde préversion de l’API introduite dans le JDK 21 avec la JEP 453.
La JEP 464 correspond, elle aussi, à la seconde préversion de la JEP 446 qui introduisait une API pour les valeurs cadrées (Scoped Values, introduite dans le JDK 20). Cette fonctionnalité doit permettre de partager des données immuables à travers et entre différents threads.
ZGC est un « nouveau » collecteur de déchets pour Java, tandis que Leyden doit accélérer le déploiement et les performances des microservices rédigés en Java.
« Nous en sommes à un point où les pauses du collecteur ZGC sont sous la milliseconde », vante Bernard Traversat. « ZGC est un collecteur de déchets, mais il peut supporter des heaps de plusieurs téraoctets. Netflix a porté sa plateforme sur le JDK 21 et utilise intensivement le nouveau collecteur de déchets », illustre-t-il.
En lien avec le collecteur de déchets par défaut G1, JDK 22 introduit la JEP 423 qui doit « réduire la latence en épinglant les régions mémoires, de sorte qu’il ne soit pas nécessaire de désactiver le ramassage des ordures pendant les régions critiques de l’interface native Java (JNI) ».
Java se convertit (doucement) au machine learning
Panama a pour objectif d’améliorer les interconnexions entre la JVM (Java Virtual Machine) et les API de langage « étranger », en priorité C. « Panama représente un long chemin permettant de simplifier l’accès à des librairies natives depuis la plateforme Java. Dans le monde du machine learning, beaucoup de kernels sont écrits en C, mais les accès sont effectués à plus haut niveau », décrit Bernard Traversat. Ces accès sont généralement permis à l’aide de scripts rédigés en Python. « Nous voulons créer un niveau d’interaction ô combien supérieur en matière de performances, comparé à Python, mais surtout bien plus sécurisé ».
« Nous voulons créer un niveau d’interaction ô combien supérieur en matière de performances, comparé à Python, mais surtout bien plus sécurisé ».
Bernard TraversatV-P, Software Development, Java Platform Group, Oracle
En ce sens, dans le JDK 22, la JEP 454 permet l’invocation de fonctions étrangères (en dehors de la JVM) à travers une API qui accède à la mémoire d’un programme, lui aussi étranger. Cette fonctionnalité est en développement depuis la JDK 19 (JEP 424) et a évolué « considérablement » dans JDK 20 (JEP 434) et JDK 21 (JEP 442). La JEP 460 correspond à la septième (!) incubation de l’API Vector, qui permet « d’exprimer les calculs vectoriels compilés au moment de l’exécution en instructions matérielles sur les architectures CPU qui les prennent en charge ».
Le projet Babylon, lui, implique une meilleure prise en charge de Java sur des GPU, et plus précisément d’écrire des kernels en Java (quand CUDA, le kernel Nvidia, est écrit en C++). « Nous voulons rendre l’exécution de programmes Java sur GPU la plus efficiente possible », avance Bernard Traversat.
Dans cette même logique autour du machine learning et du traitement de données, le JDK 22 introduit une mise à jour de l’API Stream, en vue de prendre en charge des opérations intermédiaires jusqu’alors non prises en charge par les API de la plateforme. Il s’agit de rendre « plus flexible » la création de pipelines de stream et de manipuler des flux de n’importe quelle taille.
Simplifier l’usage et l’apprentissage de Java
Quant à Amber, il doit simplifier la « grammaire » Java. Dans la même veine, Valhalla implique la révision des types Value et des génériques afin d’optimiser la mise en cache du langage. « Valhalla est notre prochain très grand projet pour unifier le système de types de Java. Aujourd’hui, nous avons des types primitifs et des objets et les développeurs doivent faire un choix. Nous voulons simplifier la chose en rendant les classes objets aussi performantes que possible », affirme Bernard Traversat.
Dans le JDK 22, c’est le projet Amber qui bénéficie le plus d’attention avec quatre fonctionnalités, dont deux en deuxième phase de préversion.
« Amber est un projet pluriannuel pour rendre Java accessible aux générations futures », résume Bernard Traversat. « Nous ne voulons plus entendre que Java est trop “verbeux”, trop dur à enseigner ».
Le JEP 447, en préversion, vise principalement à simplifier la conception de constructeurs. Les contributeurs ne veulent plus que l’appel à un autre constructeur soit nécessaire dans la première phase de développement d’un constructeur. Pour cela, le JEP 447 introduit les concepts de prologue, des instructions avant l’appel obligatoire des constructeurs super (…) ou this (…), et le contexte de préconstruction. Cela signifie qu’on peut écrire du code dans un constructeur comme on le ferait dans une méthode normale, mais sans accéder à l’objet en cours de construction.
Le JEP 456 (issu du JEP 443 du JDK 21) doit empêcher l’usage de certaines variables déclarées par les développeurs, mais qu’ils ne comptent pas utiliser. « Ces deux fonctionnalités visent à masquer la complexité de structures Java pour les jeunes développeurs », résume Bernard Traversat. Les templates String (JEP 459) doivent réduire la quantité de code à rédiger.
Mais la seconde préversion du JEP 463 est celle qui vise directement les jeunes développeurs et les pousse à adopter Java progressivement. Désactivée par défaut, elle doit permettre d’introduire les concepts de base de Java sans faire appel à des outils distincts, avant d’ajouter les concepts plus avancés. Dans ce mode d’apprentissage, le code Java, réduit à son expression minimum, ressemble fortement à un programme Python. La JEP 463 pourrait également servir à réduire le code « boilerplate » pour des programmes simples « comme les scripts et les utilitaires en ligne de commande ».
L’autre mécanisme de simplification mis en avant par la communauté et Oracle, c’est la possibilité de lancer une application Java à partir de plusieurs fichiers de code source (JEP 458). « La transition entre les petits programmes et les plus grands sera ainsi plus progressive, ce qui permettra aux développeurs de choisir s’ils veulent se donner la peine de configurer un outil de build, et à quel moment », justifient les auteurs de la proposition. Depuis le JDK 11, le lanceur d’application Java peut faire appel à des sources de code, mais il fallait qu’elles soient rangées dans un seul fichier .java.
Les effets secondaires du changement de cycle de mise à jour
Moins une simplification, qu’une tentative de résoudre les effets indésirables du changement de cycle de mise à jour, la JEP 457 entend standardiser une API Class Files pour parser, générer et transformer des fichiers de classe Java.
« Le format des fichiers de classe pouvant évoluer tous les six mois, les frameworks rencontrent plus fréquemment des fichiers de classe plus récents que la bibliothèque de fichiers de classe qu’ils intègrent. Ce décalage de version entraîne des erreurs visibles par les développeurs d’applications ou, pire encore, par les développeurs de frameworks qui tentent d’écrire du code afin d’analyser les fichiers de classe du futur et qui font un acte de foi en pensant que rien de grave ne changera », signalent les auteurs de la JEP 457. « Les développeurs de frameworks ont besoin d’une bibliothèque de fichiers de classe dont ils peuvent être sûrs qu’elle est à jour avec le JDK en cours d’exécution ».
À ce sujet, les contributeurs du projet Spring, fortement dépendant de l’OpenJDK (la version open source du JDK), exprimaient l’année dernière leur difficulté à suivre le nouveau rythme de sortie imposé par Oracle et la communauté. Selon Bernard Traversat, les fonctionnalités présentées dans le JDK 22, qui bénéficieront d’un support commercial au moment de la disponibilité de la prochaine sortie de la nouvelle version LTS, n’écrasent pas les mécanismes déjà en place dans la plateforme Java. « Nous souhaitons supporter les usagers les plus conservateurs, comme ceux plus enclins à tester les innovations », insiste-t-il.
« En investissant dans notre écosystème, il est de notre responsabilité d’aider et de soutenir tous ces mainteneurs à travers notre programme de sensibilisation à la qualité. »
Sharat ChanderSenior Director, Java Product Management, Oracle
Pour les développeurs de frameworks open source, Oracle et la communauté ont mis en place un programme de suivi (Quality Outreach Program), afin de tester les fonctionnalités des versions intermédiaires et LTS de l’OpenJDK et faire des retours. À son lancement en 2016, le programme servait aux mainteneurs de projets open source à remonter des bugs rencontrés. La majorité des projets suivis semblent s’exécuter sur l’OpenJDK 11, suivi par l’OpenJDK 21 et l’OpenJDK 17. C’est d’autant plus important que les clients d’Oracle s’appuient sur ces librairies open source dans le cadre de leur déploiement. Selon le State of Java 2023 réalisé par Azul auprès de 2 000 utilisateurs de la plateforme, la majorité des entreprises exploitent les versions Java 8, 11 et 17, mais « 43 % des répondants utilisent au moins une version commerciale qui n’est plus prise en charge par Oracle ».
« Nous sommes conscients que, pour de nombreuses entreprises et développeurs, la version de Java qu’ils utilisent n’est pas le seul élément crucial », répond Sharat Chander, Senior Director, Java Product Management chez Oracle, en réponse à la question du MagIT. « Leur chaîne d’outils de dépendance peut également jouer un rôle important et parfois les empêcher d’adopter une version plus récente de Java. Par conséquent, en investissant dans notre écosystème, il est de notre responsabilité d’aider et de soutenir tous ces mainteneurs à travers notre programme de sensibilisation à la qualité », insiste-t-il. « De plus, nous proposons désormais un support commercial pour les bibliothèques tierces de nos clients, car nous partageons la vision de notre équipe de développeurs quant à la manière dont Java interagit avec cette vaste gamme d’outils ».
