maciek905 - Fotolia
Java 23 : Oracle et la communauté poursuivent sur leur lancée
Présenté avant CloudWorld 2024 à la presse, Oracle annonce aujourd’hui la disponibilité générale de Java 23. Il s’agit d’une version intermédiaire censée attester du progrès des contributeurs dans les projets de transformation de Java qui animent la communauté depuis dix ans.
Pour rappel, Oracle et la communauté Java proposent une nouvelle version de la plateforme de développement tous les six mois. Les versions qui comptent, celles supportées à « long terme » (LTS), sortent tous les deux ans. En clair, la plupart des entreprises passeront de Java 11, 17, ou 21 à Java 25. Dix ans après sa disponibilité générale, le JDK 8 (Java Development Kit, JDK ou OpenJDK) entre en fin de vie.
Le fournisseur tente de ménager la chèvre et le chou en introduisant des fonctionnalités sans (forcément) casser les habitudes des vieux briscards du langage. Oracle a une manière plus élégante de l’exprimer. Ses porte-parole parlent de la méthode « tip and tail ». Il s’agit de trouver un équilibre entre la conservation de l’existant (la compatibilité, les utilisateurs) et l’innovation (changements majeurs, correctifs).
« Il y a des millions de développeurs qui ont des habitudes et nous ne voulons pas les aliéner en allant trop vite », confirme Chad Arimura, vice-président des relations avec les développeurs Java chez Oracle. « Nous voulons être très prudents quand nous introduisons des fonctionnalités. Nous cherchons à ce que Java demeure stable et sécurisé afin que les développeurs puissent lui faire confiance très longtemps dans leurs applications ».
Comme le JDK 22, JDK 23 intègre 12 fonctionnalités clés en sus de « centaines » de mises à jour de performance, de stabilité et de sécurité.
Seulement, quand le JDK 22 incluait trois propositions d’amélioration (Java Enhancement Proposal ou JEP) inédites, le JDK 23 n’en contient que deux.
Il y a d’abord l’extension des types primitifs dans Patterns, instanceof et switch par le biais de la JEP 455. L’objectif est d’uniformiser Java, qui, malgré les ajouts apportés dans JDK 21, présentait des restrictions d’usage quand les opérateurs cités ci-dessus sont utilisés pour effectuer du pattern matching. Cette technique sert à tester et d’extraire des valeurs de variables en fonction de leurs types et de leur structure.
La JEP 476, en préversion également, doit automatiser « l’import de tous les paquets exportés par un module ». Jusqu’à aujourd’hui, seules les classes et interfaces Object, String et Comparable étaient importés dans le paquet java.lang. Or List, Map, Stream et Path « sont devenus presque essentielles » aux développeurs Java.
« Cela simplifie la réutilisation des bibliothèques modulaires pour tous les développeurs et permet aux débutants d’utiliser plus facilement des bibliothèques tierces et des classes Java fondamentales sans avoir à apprendre où elles se trouvent dans une hiérarchie de paquets », assure Oracle.
Comme un air de déjà-vu
En deuxième préversion, l’on retrouve trois fonctionnalités : les JEP 482, 466 et 473.
La JEP 482 reprend les prérogatives de la JEP 447 introduite dans le JDK 22. Pour rappel, il s’agit de faire apparaître des déclarations avant d’invoquer explicitement un constructeur « super (…) » ou « this (…) ».
Ici, la JEP 482 doit initialiser des champs dans la même classe avant l’invocation. Il s’agit de s’assurer que les constructeurs dans les sous-classes et les super classes n’entrent pas en conflit, en garantissant l’exécution des constructeurs dans un ordre spécifique (top-down) pendant l’instanciation.
Elle-même proposée dans le JDK 22, la JEP 466 amende légèrement et simplifie l’API pour parser, générer et transformer des fichiers de classe Java (JEP 457).
La JEP 473 concerne l’API Stream Gatherers, une interface visant à créer des pipelines de stream et à manipuler des flux de n’importe quelle taille. Ici, aucun changement n’est à noter : les contributeurs n’ont pas obtenu assez de retours et lancent, pour ainsi dire, une deuxième consultation.
Trois autres fonctionnalités sont entrées en troisième préversion. Elles portent les appellations JEP 480, 481 et 477.
La JEP 480 concerne l’API dédiée à la concurrence structurée. « La concurrence structurée traite les groupes de tâches connexes exécutées dans différents threads comme une seule unité de travail, ce qui permet de rationaliser la gestion et l’annulation des erreurs, d’améliorer la fiabilité et d’accroître l’observabilité », notent les auteurs de la JEP. Introduite en incubation dans le JDK 19, modifié légèrement depuis, elle revient pour la troisième fois en préversion sans modification.
Incubée pour la première fois dans le JDK 20 (JEP 429), la JEP 481 représente l’API « Scoped value ». Celle-ci introduit une méthode pour partager des données immuables dans et entre des threads. Ici, encore, une petite modification a été effectuée afin de supprimer la méthode ScopedValue.getWhere. Il s’agit d’une interface permettant au compilateur Java « de déduire si une exception vérifiée peut être levée ».
La JEP 477, elle, concerne une fonctionnalité pour faciliter l’accès à Java aux débutants. Introduite dans le JDK 21 (JEP 445), puis remaniée dans le JDK 22 (JEP 463) en s’inspirant de Python, elle revient avec deux modifications afin de simplifier l’utilisation des classes déclarées de manière implicite. Cela profiterait également aux développeurs aguerris qui souhaitent développer de petites applications.
« De nos jours, les utilisateurs recherchent souvent des programmes plus simples et concis », avance Chad Arimura. « Beaucoup des fonctionnalités comme les classes pour la modélisation, la gestion de l’organisation, les comportements statiques et d’instance, ou l’interaction via la ligne de commande ne sont pas indispensables tant que vous ne commencez pas à développer des applications de plus grande envergure ».
Dans la même veine, la JEP 467 doit permettre d’écrire les commentaires en Markdown plutôt qu’en utilisant un mélange de HTML et de @tags spécifique à JavaDoc.
L’API Vector (JEP 469) revient dans sa huitième incubation sans de modifications substantielles afin d’acquérir de nouveau des retours utilisateurs.
La JEP 474 est sans doute une étape importante, car elle implique l’instauration par défaut du mode générationnel du collecteur de déchets ZGC et la suppression « prochaine » du mode « non générationnel » qui freinerait l’avancée du projet. La promesse ? Optimiser considérablement la collection de déchets.
Enfin, la JEP 471 signifie la fin prochaine des méthodes d’accès mémoire dans sun.misc.Unsafe. Elle introduit une suite d’outils pour vérifier si une application s’appuie directement ou indirectement sur ces méthodes.
Pas de ralentissement de l’innovation selon Oracle
De l’extérieur, ces menues évolutions semblent indiquer un ralentissement du projet Java. Pour rappel, ces JEP sont rattachées à des dossiers en cours depuis quelques années : Valhalla, Loom, Amber, Leyden, Panama, etc. « Je dirais que c’est plutôt le contraire. Cela fait sept ans que je suis à ce poste et c’est presque comme si les choses s’accéléraient », assure Chad Arimura. « Certaines versions ont tendance à avoir plus de préversions que d’autres, mais ces dispositions donnent un aperçu de l’avenir », ajoute-t-il.
« Les premières préversions sont apparues avec Java 10. Par exemple, dans le cadre du projet Amber, beaucoup de fonctionnalités sont devenues standards ».
Le projet Amber vise à faire évoluer Java « en vue d’améliorer la productivité des développeurs », dixit Oracle. Quatre des douze fonctionnalités « clés » du JDK 23 sont issues d’Amber (JEP 455, 476, 477, 482).
Malgré les propos de Chad Arimura, il semble évident que le JDK 25 sera davantage surveillé. Ce n’est pas pour tout de suite. Pour l’instant, il n’y a qu’une seule JEP au programme du JDK 24 dont la sortie est prévue en mars 2025, mois pendant lequel Oracle organisera son événement JavaOne à Redwood Shores, dans le comté de San Mateo, près de San Francisco. Le JDK 25 est attendu pour le mois de septembre 2025.
