Java 17 : Oracle ajuste sa stratégie de support à long terme
Trois ans après la version 11, Oracle rend disponible l’OpenJDK 17, une mouture supportée à long terme. Si elle ne met pas fin aux projets de modernisation de Java, cette itération donne l’occasion au fournisseur de poursuivre son opération séduction auprès des entreprises.
L’OpenJDK 17 introduit par Oracle ce 14 septembre n’est pas la mise à jour la plus novatrice de ce framework. Cette version apporte principalement le support de la nouvelle architecture Apple Silicon pour macOS (AArch64 – le mode 64 bits de l’architecture ARMv8) et des pipelines de rendu 2D (JEP 382) via l’API Apple Metal qui remplace OpenGPL.
Aussi, Java 17 entérine la disponibilité des sealed classes. Accessibles depuis Java 15 dans le cadre du projet Amber, ces classes scellées doivent ajouter des contrôles sur les classes qui peuvent étendre ou non des sous-classes. Cette capacité est également compatible avec les interfaces. Les sealed classes sont associées à la fonction record (en preview dans Java 14), utilisée pour diminuer le code « passe-plat » lors de la création de classes immuables souvent reliées à des types algébriques.
Les classes scellées sont directement inspirées de Scala et de Kotlin et doivent faciliter le support du pattern matching for switch, disponible en préversion dans Java 17. Le pattern matching for switch « permet de tester une expression par rapport à un certain nombre de modèles, chacun ayant une action spécifique, de sorte que les requêtes complexes orientées données peuvent être exprimées de manière concise et sûre », peut-on lire dans la JEP associée. Une fonctionnalité similaire est disponible depuis Java 16 pour les opérateurs InstanceOf.
Comme promis, l’OpenJDK 17 implémente un générateur de nombres pseudoaléatoires (JEP 356) amélioré via une API uniforme, et remet au goût du jour les opérations en virgule flottante systématiquement strictes (JEP 306). La JEP 415 apporte des filtres de désérialisation spécifiques aux contextes à l’intérieur de la JVM. L’objectif est d’améliorer la JEP 290, disponible depuis Java 9 afin d’empêcher les attaques par désérialisation.
En incubation, la JEP 412 augure l’invocation de fonctions étrangères en dehors de la JVM à l’aide de l’API Memory Access dans le but de remplacer la Java Native Interface (JNI) et de simplifier et de sécuriser cette capacité. De son côté, la JEP 414 – en seconde incubation – correspond à l’API Vector employée pour exprimer des calculs vectoriels compilés à l’exécution sur les architectures CPU supportées, afin d’améliorer les performances par rapport aux calculs scalaires.
Java 17 comprend deux dépréciations : celle de l’API Applet, et du Security Manager, un outil datant de Java 1.0 utilisé pour exécuter les applets dans des sandbox. L’API RMI (Remote Method Activation), tout comme les compilateurs expérimentaux AOT et JIT ont été retirés, puisque GraalVM dispose de ses propres outils.
Une prochaine version LTS prévue dès 2023
Même si les projets de modernisation de Java Amber, Loom, Panama et Valhalla ne sont pas terminés, Java 17 est néanmoins une version LTS pour la plupart des éditeurs. Oracle soutiendra Oracle Java SE 17 jusqu’en septembre 2026 via le support Premier, jusqu’en septembre 2029 avec le support étendu, et les clients ont toujours l’accès au support durable (à vie tant que l’utilisateur paie).
Selon Chad Arimura, VP Java Developer Advocacy chez Oracle, les développeurs ayant déjà opté pour Java 11 ne seront pas déstabilisés lors de l’adoption de Java 17. « Passer de Java 8 à 11 ou de Java 11 à 17 ressemble beaucoup à la migration de Java 6 vers 7 et de 7 vers 8. Vue de loin, l’on dirait qu’il n’y a pas une quantité significative de développement », déclare-t-il. Sur le papier, l’évangéliste n’a pas tort. Quatre ans séparent JDK 8 et JDK 11. Entre 2014 et 2018, Oracle et la communauté ont introduit 120 propositions d’améliorations, contre 74 depuis la sortie de JDK 12.
Le changement de cadence des publications influerait pourtant sur la stabilité des différentes versions. « Auparavant, les développeurs qui travaillent sur le JDK voulaient parfois s’assurer qu’ils avaient introduit des fonctionnalités clés. Les ajouts ont donc parfois été précipités parce que les développeurs savaient qu’ils avaient le temps pour stabiliser les versions. L’écosystème allait de toute façon prendre un an ou plus pour rattraper le retard dans leurs applications et leurs dépendances », explique Chad Arimura. « Passer de 11 à 17 est très différent parce que la cadence de publication de six mois a permis aux bibliothèques et aux frameworks de rester à jour. Avec la version 17, non seulement le code est plus stable, mais la plupart des choses dont vous dépendez sont également disponibles », vante-t-il.
Seulement, ce scénario se vérifie davantage pour les entreprises et les développeurs qui ont adopté les versions non LTS de l’OpenJDK accessibles entretemps. Ce choix ne semble pourtant pas très répandu chez les usagers de Java qui pourront cependant expérimenter un bon lot de fonctionnalités. De plus, Oracle prévoit d’accélérer la cadence des sorties LTS. La prochaine version supportée à long terme sera disponible en 2023, soit d’ici deux ans.
Dans son JVM Ecosystem Report 2021, Snyk a interrogé plus de 2 000 développeurs Java. Près de 60 % d’entre eux (59,9 %) emploient encore JDK 8 dans des environnements en production, 61,5 % déclarent utiliser JDK 11 et 11,7 % ont installé Java 15.
Dans les environnements en développement, seulement, 2,7 % des répondants exploitent Java 17 dans sa version early access, 25,6 % ont déployé Java 15, plus de 64 % emploient Java 11 et 50,1 % ont toujours Java 8.
Une souscription gratuite pour Oracle JDK
Leurs employeurs ne sont pas forcément clients de la firme dirigée par Larry Ellison, mais la majorité des développeurs utilise Oracle OpenJDK (28 %) et Oracle JDK (23 %) en production. Pour autant, la plateforme open source AdoptOpenJDK remporte un succès certain (44,1 % d’adoption en production) auprès des usagers de Snyk.
« Nous mettons à disposition une nouvelle licence gratuite pour l’usage d’Oracle JDK en production pendant trois ans. »
Chad ArimuraVP Java Developer Advocacy, Oracle
De son côté, Oracle défend fermement la souscription Oracle Java SE, qui serait adoptée par des « milliers de clients » de toute taille. L’offre profiterait d’un haut taux de renouvellement et d’un Net Promoter Score tout aussi bon. Néanmoins, le fournisseur de cloud semble vouloir retenir et attirer les entreprises, même si elles ne paient plus.
« Ce que nous avons compris, c’est que les clients ne souhaitent plus être contraints de payer ou de passer à une distribution open source du JDK. Nous annonçons donc que nous mettons à disposition une nouvelle licence gratuite pour l’usage d’Oracle JDK en production pendant trois ans, soit un an de plus que la prochaine version LTS », affirme Chad Arimura.
Pour rappel, la firme avait rendu payante l’utilisation en production d’Oracle JDK depuis la version 11 en 2018, ce qui avait décidé certains développeurs et entreprises à se tourner vers d’autres distributions. Cette décision ressemble au choix de Red Hat de proposer une souscription gratuite à RHEL après l’abandon de CentOS Linux. Pour autant, OpenJDK reste bien sous licence GPL 2 avec l’exception ClassPath.
Java Management Service
Oracle tient à rappeler la disponibilité de Java Management Service (JMS), un outil qui doit permettre aux entreprises d’administrer les runtimes et les applications Java, qu’ils soient hébergés sur site ou dans le cloud d’Oracle. Ce service est inclus avec la souscription Oracle Java SE, sans surcoût, et est accessible depuis les 20 régions d’Oracle Cloud Infrastructure.
« JMS vous aide à répondre à un certain nombre de questions. Quelles sont toutes les versions de Java que j’ai installées ? Quelles versions sont utilisées par quelles applications ? Toutes mes versions Java sont-elles à jour et sécurisées ? Avons-nous tous les derniers correctifs de sécurité disponibles sur ce service de gestion Java ? », liste Chad Arimura.
JMS doit aussi apporter un outil de supervision des performances et comprendra prochainement un système de recommandations similaire à celui de MySQL Heatwave, mais pour le code Java embarqué dans les JVM. « Un modèle de machine learning inspectera les temps de réponse, les drapeaux JVM, les ralentissements possibles afin de proposer des suggestions d’optimisation », résume le VP Java Developer Advocacy.
