En attendant Java 21, voilà l’OpenJDK 20

Java : grands projets, mais petits pas

Le SVP évoque (encore) les nombreux projets en cours : Amber, Loom, Leyden, Panama, Valhalla ou encore ZGC.

Le projet Amber vise à ajouter de petites fonctionnalités centrées sur la productivité de Java. Dans l’OpenJDK 20, les Record Patterns entrent dans une phase de seconde préversion, tandis que la corrélation de patterns pour les expressions switch passe en quatrième préversion. En disponibilité générale depuis JDK 16 (mais introduite dans Java 14), les classes records visent à créer des objets dont les attributs ont des références immuables. Plus précisément, il s’agissait d’enrichir les expressions instanceof.

Selon Oracle, les record patterns visent à exprimer des requêtes de données « plus sophistiquées et plus composables ». Avec JDK 20, les contributeurs introduisent un mécanisme pour imbriquer les record et les types.

« Les patterns imbriqués éliminent la complexité accidentelle de la navigation dans les objets afin que nous puissions nous concentrer sur les données exprimées par ces objets », résument les contributeurs du projet.

Les améliorations de la JEP (JDK Ehancement Proposal) 432 visent à améliorer le support du pattern matching, une fonction qui elle-même bénéficie de petits ajouts avec la JEP 433, afin qu’elle puisse prendre en charge les expressions switch.

« Il s’agit d’étendre la notion de pattern matching à un plus grand nombre de composants de Java », résume George Saab. « Cela permet de combiner les styles de programmation ».

Du projet Loom, Java 20 hérite des JEP 429, 436 et 437, associées aux threads virtuels.

« L’intérêt pour les threads virtuels est très fort », affirme George Saab. « Les contributeurs aux bibliothèques et au framework Java se sont empressés de les prendre en charge. Je pense que c’est un excellent exemple du soin et de l’attention apportés par les développeurs qui travaillent à l’évolution de Java ».

En incubateur, la JEP 429, à savoir les valeurs cadrées (Scoped Values), doit permettre le partage de données immuables à travers et entre différents threads, une technique plus adaptée que les threads locaux au moment d’exploiter plusieurs centaines, voire plusieurs milliers de threads virtuels.

La JEP 436, renvoie à une amélioration légère des threads virtuels liée aux changements des API de la JEP 425 ajoutant des nouvelles méthodes pour arrêter ou mettre en veille les threads.

Quant à la JEP 437, arrivée en deuxième période d’incubation, elle doit améliorer la concurrence structurée « en apportant des moyens pour renforcer la maintenabilité, la robustesse et l’observabilité du code multithreadé ».

Enfin, le projet Panama, doit permettre d’invoquer du code situé en dehors de la JVM, dans des environnements « non-Java », via API. La deuxième préversion de la JEP 434 doit optimiser la gestion des segments mémoire, des abstractions liées à certaines régions de la RAM, visant à restreindre la concurrence entre les charges de travail.

La JEP 438, elle, correspond à la correction de bugs et l’optimisation de l’API Vector. Cette interface a été introduite en incubation dans JDK 16 dans le but 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. Peu de changement donc et pourtant, il s’agit de la cinquième phase d’incubation. De fait, les coordinateurs du projet Valhalla, lancé en 2014 pour apporter des types de données plus génériques supportés par la JVM, veulent pouvoir la revoir.

« En plus des JEP, il faut aussi noter des milliers de mises à jour de sécurité et de performance [2 314 issues JIRA corrigées précisément N.D.L.R] », assure George Saab.

Pour autant, il y a peu de fonctionnalités majeures à se mettre sous la dent. Il faut surtout retenir des ajouts liés à sécurité : le protocole DTLS 1.0 n’est plus supporté par défaut ; deux nouvelles méthodes de la class javax.net.ssl permettent de configurer les algorithmes d’échanges de clés dans une connexion DTLS ; de nouvelles propriétés de sécurité affectent tout un lot de classes lié à JNDI ; et l’observabilité de la JVM a été optimisée via les Java Flight Recorder.

En outre, le collecteur de déchets a été modifié et les contributeurs ont ajouté le support d’Unicode 15.0.

Un amuse-bouche avant la disponibilité de l’OpenJDK 21

Pour rappel, Java dépend désormais d’un cycle de mise à jour bisannuel. Cette mouture n’est qu’une étape intermédiaire avant la disponibilité en septembre prochain du JDK 21, qui, lui, sera supporté à long terme.

Il est donc peu probable que les entreprises adoptent Java 20. Pour autant, le responsable estime que la disponibilité de ces versions intermédiaires, disponibles plus rapidement, permet d’ajuster les développements.

« Les fonctions préliminaires ne sont pas des bêtas, elles peuvent être utilisées en production », insiste George Saab. « Elles requièrent une activation manuelle, mais nous recevons beaucoup de retours pour les améliorer ».

Ces améliorations incrémentales auraient également influencé le succès de la plateforme de développement ces deux dernières années. Les développeurs adopteraient petit à petit les nouvelles fonctionnalités.

Un nouveau rythme difficile à suivre ?

Concernant les versions LTS de l’OpenJDK, George Saab observe que beaucoup d’éditeurs et de contributeurs aux librairies liées à l’écosystème Java se sont calqués sur cette nouvelle cadence. C’est le cas de VMware, principal contributeur au framework Spring. Une adaptation intéressante pour cette communauté annexe, mais qui se fait, semble-t-il, à marche forcée. Sur Twitter, certains développeurs exposent le fait qu’ils ne peuvent plus suivre la cadence des mises à jour ou que leurs entreprises n’ont pas encore sauté le pas vers des versions « récentes » de l’OpenJDK (11 ou 17, de préférence).

Les porte-parole d’Oracle perçoivent davantage les gains de cette nouvelle cadence, tout comme ils ont rappelé tout l’intérêt du remaniement de la licence Java SE pour les nouveaux clients. Pour rappel, le montant à payer auprès du fournisseur n’est plus calculé sur le volume de postes de travail et de processeurs de serveurs équipés de la licence, mais sur le nombre d’employés dans l’entreprise.

« Le nombre d’employés est généralement connu de la plupart des entreprises, ce qui simplifie le processus pour elles. Il convient de noter que les clients existants qui se sont abonnés sur la base de l’ancienne métrique sont libres de continuer à l’utiliser s’ils le souhaitent », affirme George Saab d’une voix légèrement hésitante. Ce sujet risque d’animer quelques conversations lors du Java Developer Day ayant lieu ce 21 mars.

Oracle a toutefois quelques fonctionnalités potentiellement intéressantes pour les organisations. Par exemple, Java SE Enterprise Performance Pack doit permettre de conserver les charges de travail pensées pour le JDK 8 en profitant des ajouts de la dernière version LTS en date, le JDK 17. Il détient également les clés d’une version entreprise de GraalVM, la fameuse machine virtuelle polyglotte censée réduire le temps de démarrage et la consommation de mémoire des microservices.