L’IA et le chiffrement post-quantique guident l’avenir de Java
Avec Java 24, la communauté derrière l’OpenJDK se prépare au chiffrement post-quantique et à l’IA, mais apporte surtout des optimisations avant la prochaine version supportée à long terme.
Depuis le changement de cycle de mise à jour du Java Development Kit (JDK), il est habituel de voir le nombre de propositions de fonctionnalités (Java Enhanced Proposals ou JEPs) augmenter. Java 24, la dernière mise à jour avant la prochaine version supportée à long terme de la plateforme/langage de programmation, fait exception. Elle comporte 24 JEPs, soit autant de fonctionnalités notables que Java 23 et 22 réunis. Sans compter les quelque 300 petites modifications ou corrections de bugs.
« Dans l’ensemble, la quantité de nouvelles fonctionnalités que nous sommes en mesure d’intégrer dans ces versions augmente progressivement », déclare George Saab, vice-président senior responsable du développement de la plateforme Java chez Oracle.
« Nous anticipons de mieux en mieux les évolutions et les changements, et nous voyons plus de contributions en général. »
George SaabV-P senior responsable du développement de la plateforme Java, Oracle
« Je pense que cela témoigne des efforts des personnes qui travaillent sur ce projet au sein de mon équipe et de la communauté de l’OpenJDK », poursuit-il. « En fait, nous anticipons de mieux en mieux les évolutions et les changements, et nous voyons plus de contributions en général ».
Il faut dire que la stratégie impulsée par Oracle consiste en l’ajout d’améliorations par petites touches tout en conservant le plus possible l’existant.
Les JEP 488 (types primitifs dans les patterns, les expressions instanceof et switch), 492 (corps de constructeurs flexibles), 494 (déclaration d’importation de modules) et 495 (fichiers sources simples et méthodes principales d’instance) visent ainsi à solidifier le langage et à le rendre plus flexible. Toujours en préversion, ces fonctionnalités devraient être prêtes pour la sortie de l’OpenJDK 25.
Justement, le système d’incubation et de préversion favorise la hausse du nombre de JEP par version.
Par exemple, la Vector API issu du projet Panama en est à sa neuvième incubation (JEP 489). Elle permet de prendre en charge des « calculs scalaires » (des opérations vectorielles) par « certains CPU » à l’exécution. L’idée était, lors de la première incubation dans le JDK 16, de favoriser la parallélisation de certains traitements liés au machine learning, à l’algèbre linéaire et au chiffrement.
Vector API devient finalement l’emblème de deux objectifs de la feuille de route de Java : l’IA et le chiffrement.
Adapter Java à l’IA
Issu du projet Panama – visant à simplifier les interconnexions entre la JVM et les langages « étrangers » (non-java) –, la Vector API va rejoindre le projet Valhalla. Valhalla est un projet initié pour améliorer les types et optimiser la mise en cache du langage.
Selon Donald Smith, vice-président gestion du produit chez Oracle, les autres fonctionnalités issues du projet Panama et l’API Foreign Function Memory ont facilité l’intégration de librairies d’IA écrites dans d’autres langages avec Java. « Cela permet aux SDK de les exposer à Java pour les relier à la logique métier », commente-t-il.
« [Les projets] Valhalla et Babylon […] faciliteront l’exécution directe du code Java sur un GPU, mais aussi l’introduction de types complexes, qui sont courants dans les domaines du machine learning et du calcul IA. »
Donald SmithV-P gestion du produit, Oracle
Dans l’OpenJDK 24, les types primitifs dans les Patterns, instanceof et les switch (JEP 488) faciliteraient justement l’intégration de la logique métier lors de l’exécution (l’inférence) de modèles d’IA. La déclaration d’importation de modules (JEP 492) permettrait d’appeler des librairies, des outils et des services dont les LLM ont besoin pour accomplir une tâche dans une application Java.
C’est plus ou moins accidentel : ces fonctionnalités n’ont pas été spécifiquement créées pour gérer des charges de travail d’IA. C’est moins vrai pour la Vector API, les projets Babylon et Valhalla qui évoluent en vue de cette prise en charge.
« [Les projets] Valhalla et Babylon sont davantage tournés vers l’avenir », déclare Donald Smith. « Ils faciliteront l’exécution directe du code Java sur un GPU, mais aussi l’introduction de types complexes, qui sont courants dans les domaines du machine learning et du calcul IA ». C’était déjà un objectif affiché lors de la sortie du JDK 22.
Chiffrement post-quantique : les contributeurs adoptent les standards du NIST
C’est avec la même prudence que les principaux contributeurs approchent le chiffrement post-quantique. En préversion, la JEP 478 introduit une API de fonction de dérivation servant à prendre en compte le chiffrement post-quantique pour les données en transit.
La JEP 496 ajoute la prise en charge des mécanismes d’encapsulation de clés symétriques générés par des algorithmes à treillis (Lattice-Based Key-Encapsulation Mechanism ou ML-KEM). Cette implémentation est tirée du standard FIPS 203 créé par le NIST (National Institute of Standards and Technology). La JEP 497 vise à intégrer les algorithmes à treillis consacrés à la signature numérique de données (ML-DSA), en droite lignée du standard FIPS 204. Ici, Oracle et la communauté entendent prendre en charge l’ensemble des variantes des algorithmes ML-KEM et ML-DSA. Ce n’est pas l’approche de Google Cloud qui les a triés sur le volet.
« Ces nouvelles JEPs ne sont pas destinées à être directement utilisées par un développeur d’applications aujourd’hui », signale Donald Smith. « En revanche, elles seront exploitées par les développeurs de bibliothèques, en particulier dans le domaine de la sécurité et de la cryptographie ».
« La suite logique consistera à ajouter la prise en charge de TLS et la signature de code sur la base de ces nouvelles API. »
Donald SmithV-P gestion du produit, Oracle
Et Donald Smith de préciser que les « premières briques » de la prise en charge du chiffrement post-quantique ont été intégrées à partir du JDK 21. « Après avoir reçu des retours confirmant que ces premiers algorithmes étaient corrects, nous franchissons maintenant une nouvelle étape », indique-t-il. « La suite logique consistera à ajouter la prise en charge de TLS et la signature de code sur la base de ces nouvelles API », poursuit-il. « Cependant, avant cela, nous devons recueillir davantage de retours et affiner les implémentations ».
Plusieurs améliorations de performance consacrées à la JVM HotSpot (JEP 450, JEP 483, JEP 471), du collecteur de déchets ZCG, à la parallélisation des charges de travail (JEP 491, JEP 499) et au traitement en mémoire vive (JEP 475) intéresseront davantage les développeurs.
Tout comme l’ajout ou l’amélioration de fonctionnalités liés au transfert et à la transformation de données et de fichiers de classe (JEP 485, JEP 484, JEP 487).
En route vers Java 25
Il faut noter la suppression du port x86 Windows 32 bits et la dépréciation du port x86 32 bits avant sa suppression. En effet, Microsoft a cessé de mettre à jour les versions 32 bits de Windows 10 en septembre 2024. Intel a par ailleurs envisagé la fin de la prise en charge de ce jeu d’instructions avant de se rapprocher d’AMD pour tracer l’avenir de l’architecture x86.
En outre, l’usage de la Java Native Interface sera bientôt restreint. Pour rappel, il s’agit d’une méthode pour faire interagir le code Java s’exécutant dans une JVM avec le code « natif » des programmes spécifiques à une plateforme matérielle ou logicielle (OS), généralement du C ou du C++. Cette implémentation est désormais considérée comme « risquée » à la fois en matière de performance et de sécurité. La limitation devrait s’accompagner de règles de contrôle d’accès qui s’appliqueront également à l’API Foreign Function Memory au moment d’appeler du code natif et vice-versa.
Enfin, le gestionnaire de sécurité est désactivé définitivement. Les contributeurs estiment que cette approche du contrôle de l’exécution du code Java par privilège est un frein technique à l’évolution de Java et contre-productive en matière de cybersécurité. Peu de librairies connexes au langage Java l’utiliseraient.
Selon le State of Java Report d’Azul, Java 17 est la version LTS la plus déployée en production. Les versions 8 et 11 n’ont pas disparu des systèmes des entreprises, tandis que le passage à Java 21 était en hausse en 2024. Pour les porte-parole d’Oracle, il est déjà temps de se préparer à la migration vers Java 25.
« Java 24 n’est pas si loin de Java 25. Les changements incrémentaux du JDK seront très limités », prévient George Saab. « Si votre application fonctionne bien avec le JDK 24, ce sera probablement facile pour vous de migrer ». La disponibilité de Java 25 est prévue en septembre 2025..
