peshkova - stock.adobe.com
IA, microservices, chiffrement post-quantique : la feuille de route de Java se précise
L’OpenJDK 26 est une version mineure, mais Oracle et la communauté ont plusieurs projets en cours. Ils dévoilent les axes de développement majeurs pour les deux ans à venir.
Après une version LTS lancée sous l’angle de la performance en septembre, Java 26 (OpenJDK) est en disponibilité générale depuis le 17 mars. Avec 10 JEPs (Java Ehancement Proposals), cette version intermédiaire ne fera pas date dans l’histoire du langage de programmation.
Une quatrième préversion pour les types primitifs Patterns, instanceof et Switch, la deuxième préversion des constantes lâches et du chiffrement post-quantique, la sixième préversion des concurrences structurées, la onzième incubation de l’API vectorielle, des énièmes améliorations de la collection de déchets avec G1 et la mise en cache des objets « Ahead of Time » avec ZGC et les autres collecteurs… Les porte-parole d’Oracle le disent eux-mêmes : la mise à jour est incrémentale.
Si mineure que le fournisseur liste même 19 des « centaines » de correctifs et ajouts secondaires ; chose qu’il ne fait pas souvent. Ceux-ci se rapportent à l’amélioration des performances (threads virtuels, meilleur suivi de la consommation du CPU par le collecteur de déchets, etc.) et l’optimisation de fonctions de sécurité (prise en compte native des clés publiques hybrides, TLS configurables, chiffrement ML-DSA des fichiers JAR, etc.).
Cette baisse de régime est assumée et un effet souhaité du programme de mises à jour bisannuelles. Cela ne veut pas dire que la communauté et Oracle se reposent sur leurs lauriers. Ensemble, ils planifient le contenu des feuilles de route des OpenJDK 27, 28 (qui sera la prochaine version supportée à long terme, en septembre 2027) et 29.
Detroit : rapprocher Java de JavaScript et Python
Ainsi, le contributeur principal annonce le lancement du projet Detroit. Il vise à rapprocher Java de deux autres langages de programmation populaires chez les développeurs, à savoir JavaScript et Python.
« Au fil des ans, nous avons observé que les développeurs en entreprise désirent appeler des fonctions JavaScript depuis Java », explique Bernard Traversat, vice-président du développement logiciel–plateforme Java chez Oracle. « De la même manière, les ingénieurs veulent pouvoir appeler des librairies d’IA Python directement depuis un programme Java », affirme-t-il lors d’un point presse. Une capacité nécessaire, si Oracle et la communauté Java veulent rester pertinents à l’heure de l’IA agentique.
La communauté avait déjà rendu possible l’appel de moteurs d’exécution natifs pour les langages tels que C et C++ (via la Java Native Interface). « Le projet Detroit ajoutera des couches légères qui permettront les appels et des callbacks de JavaScript à travers Java », ajoute le vice-président du développement logiciel chez Oracle.
En ce sens, le projet Detroit vise à intégrer les moteurs V8 pour JavaScript (créés par Google) et CPython. « Nous pourrons nous appuyer sur toutes les optimisations et tous les investissements effectués par les communautés derrière V8 et CPython pour les apporter à l’écosystème Java », promet-il. Sans surprise, les contributeurs de Java exploiteront le modèle de sécurité applicable aux fonctions étrangères.
Les processus V8 et CPython seront directement embarqués dans les processus de la JVM. « Par le passé, nous avions mené le projet Nashorn avec lequel nous avions essayé d’implémenter JavaScript par-dessus la JVM », rappelle Bernard Traversat. « Or, des langages comme JavaScript et Python n’ont pas des spécifications aussi strictes que Java, ce qui provoquait beaucoup d’erreurs. Maintenant, nous allons embarquer V8 et CPython pour une compatibilité exhaustive ».
Detroit n’est pas un nom inconnu. C’était un projet lancé en 2018 et qui n’avait pas « bénéficié d’un soutien fort de la communauté », dixit les ingénieurs Oracle qui ont proposé de le relancer. Il avait été dissous en 2024. Le concept de marier Java et JavaScript n’avait jamais quitté certains esprits (le sujet fait débat dans la communauté). Mais c’est l’émergence de l’IA générative qui justifie pleinement sa relance. Il réclamera de « pousser les limites de l’API FFM », ce qui pourrait impacter le projet Panama. Cela risque de se faire sans GraalJS, une version du moteur polyglotte GraalVM dédiée à JavaScript.
Faire d’Helidon le framework de microservices par défaut de Java
L’autre annonce importante, c’est le rapprochement de l’OpenJDK et d’Helidon, un framework de microservices pour Java, tels Quarkus et Spring Boot. Ce projet open source est développé par Oracle depuis 2015, mais libéré en 2018. Il consiste en l’exécution de microservices par le moteur event-driven asynchrone Netty. Comme souvent, il s’agit d’accélérer le démarrage d’application Java, optimisé pour consommer moins de mémoire vive et pour occuper un espace de stockage réduit. Leur cible de déploiement est principalement le cloud.
Les porteurs d’Helidon s’aligneront formellement sur le rythme de mise à jour rigoureux de l’OpenJDK. C’était déjà en partie le cas. « Par exemple, quand les threads virtuels ont été rendus disponibles, Helidon était l’un des premiers projets à l’intégrer », illustre Chad Arimura, vice-président des relations développeurs chez Oracle.
Ensuite, Oracle proposera une incorporation d’Helidon dans l’OpenJDK.
« Nous souhaitons aligner les choses afin de nous assurer d’avoir une solution de confiance pour les développeurs qui travaillent sur les microservices et l’IA agentique », affirme Chad Arimura, vice-président des relations développeurs chez Oracle. « La version 4.4 d’Helidon sera bientôt disponible. Une fois la transition effectuée, ces versions s’aligneront sur le modèle “tip and tail” du JDK, c’est-à-dire sur les versions 27, 28, puis 29. Helidon sera donc supporté à long terme à partir de la Java 29 », précise-t-il.
Clairement, Oracle tente lui aussi de se faire une place dans un écosystème où ses coopétiteurs sont bien plus visibles.
Quarkus est principalement soutenu par Red Hat, tandis que Spring Boot est porté par Broadcom/VMware. « Spring Boot est l’un des frameworks les plus populaires, évidemment. Quarkus suit de près. Mais Helidon a gagné des galons sur cette scène », assure Chad Arimura auprès du MagIT. « Nous espérons voir d’autres frameworks émerger, car nous aimons avoir beaucoup d’options dans la communauté ».
Tenter une percée dans l’IA
Concernant l’IA agentique, les porte-parole d’Oracle vantent la prise en charge par Helidon du protocole MCP et la disponibilité d’un serveur associé qui exploite les threads virtuels. L’entreprise mise aussi sur la compatibilité avec Langchain4J, une version du fameux framework genAI dédié au langage Java. Et d’insister sur l’intérêt des types primitifs, de l’API vectorielle, de la concurrence structurée, des constantes lâches et de l’amélioration des collecteurs de déchets dans le développement d’applications IA.
« Nous pensons également que Java peut être un très bon langage et une plateforme de choix pour l’entraînement, le fine-tuning et l’inférence de modèles d’IA », ajoute Bernard Traversat. Malgré l’intégration avec Python, Oracle cherche toujours à remplacer ce langage très populaire dans ces domaines. « Les projets Java comme Panama, Valhalla et bientôt Babylon ont été développés en ce sens ».
Les contributeurs de Pytorch, JAX et des outils comme vLLM, tous développés ou centrés sur Python, ont encore de beaux jours.
« Nous reconnaissons toutefois qu’il y a encore beaucoup de travail à faire concernant l’inférence sur des puces spécifiques et l’optimisation du JDK pour le traitement des très grands volumes de données », affirme Bernard Traversat.
Il y a un sujet connexe. Génération de code oblige, les contributeurs de l’OpenJDK doivent décider d’une politique claire en matière de contribution. « Nous espérons établir une règle claire en la matière, en déterminant ce qui est permis de ce qui ne l’est pas », indique le responsable. « Il faudra de toute façon permettre l’usage de l’IA. Sinon, nous allons être à la traîne », prévient-il.
En attendant, ils espèrent poursuivre le développement de la prise en charge des clés hybrides utilisées pour le chiffrement post-quantique. « Nous nous préparons à être les premiers à prendre en charge le chiffrement hybride à travers un protocole post-quantique et le standard TLS 4.0 à partir du JDK 27 », informe le responsable. D’après lui, Oracle ferait déjà en sorte que son implémentation des protocoles post-quantiques soit compatible avec les solutions des équipementiers. En outre, ce chiffrement hybride sera rétroporté pour Java 8, 17 et 21.
Pour son compte cette fois-ci, le fournisseur relance le support commercial du framework front-end/UX JavaFX. À cette occasion, il prolonge le support de JavaFX pour le JDK 8 jusqu’en mars 2027. JavaFX 25 et 26 sont disponibles, tandis que les versions 8,17 et 21 devraient sortir au cours de l’année. Ce support est encadré par l’offre Oracle Java Verified Portfolio (Oracle JVP). Celle-ci rassemble une bonne partie de la pile d’outils, de frameworks et de bibliothèques conçus ou pris en charge par Oracle. Tous ceux « qui n’ont pas vocation à être dans Oracle JDK ». Au lancement, le JVP intègre JavaFX, le plugin « Java Platform Extension for Visual Code » (qui supporte désormais les notebooks au format Jupyter) et Helidon.
À noter qu’Oracle JVP est inclus dans Java SE. Bien conscient de la montée en puissance de la concurrence, Oracle ouvre un peu son offre, sans toutefois modifier son « motto » : le groupe se perçoit encore et toujours comme le meilleur candidat pour le support d’applications Java.
