Oracle a récemment publié la version 15 du langage de programmation et la machine virtuelle Java. Dans la nouvelle cadence de publication d'OpenJDK, cela signifie que le travail est déjà passé à la version 16, qui devrait être publiée en mars 2021. Les nouvelles fonctionnalités incluent des mises à niveau procédurales, de nouvelles API et de nouveaux outils, des portages vers des système d'exploitation, une encapsulation forte des composants internes JDK par défaut, etc.
Les nouvelles fonctionnalités annoncées peuvent être subdivisées en plusieurs catégories, en commençant par quelques mises à jour des procédures pour développer OpenJDK :
- Migrate from Mercurial to Git (JEP 357)
- Migrate to GitHub (JEP 369)
- Enable C++14 Language Features (JEP 347)
Il y a de nouvelles API et de nouveaux outils - la plupart d'entre eux encore en incubation :
- Vector API (Incubator) (JEP 338)
- Foreign Linker API (Incubator) (JEP 389)
- Foreign-Memory Access API (Third Incubator) (JEP 393)
- Unix-Domain Socket Channels (JEP 380)
- Packaging Tool (JEP 392)
Les trois premiers sont la livraison de fonctionnalités du Projet Panama, qui est le projet OpenJDK visant à améliorer la capacité du code géré par la JVM code pour interagir avec des API bien définies mais «étrangères» (c'est-à-dire non Java). En particulier, cela inclura les interfaces couramment utilisées par les bibliothèques C. Le projet Panama peut être considéré vaguement comme une "réimagination de JNI", mais il contient bien plus que cela. Ces JEP sont toujours en incubation et ne deviendront définitifs que dans une future version de Java.
Une autre catégorie de JEP en cours de livraison concerne les améliorations mineures apportées à la machine virtuelle :
Le premier de ceux-ci permet à la JVM de libérer la mémoire inutilisée de la zone de métadonnées internes vers le système d'exploitation et le second est une amélioration des performances du ramasse-miettes ZGC.
Un certain nombre de nouveaux ports d'OpenJDK vers différents systèmes d'exploitation sont attendus :
Cela inclut le premier port officiel et pris en charge d'Alpine Linux dans (bien que les systèmes Azul offrent un support payant pour Java sur Alpine depuis un certain temps).
La catégorie des portages peut également inclure JEP 391 (port macOS / AArch64), qui est le portage qui permeattre d'utiliser Java sur la nouvelle architecture Silicon d'Apple. Ceci est en cours et bénéficie du soutien d'Azul Systems et de Microsoft (pour en savoir plus, lisez la récente conférence QCon de Monica Beckwith ) mais n'a pas encore été officiellement ciblé pour Java 16 - mais l'équipe du projet a discuté de la possibilité qu'il soit livré dans le cadre de la version.
Une autre catégorie est la prochaine itération des fonctionnalités du projet Amber :
- Pattern Matching for instanceof (JEP 394)
- Records (JEP 395)
- Sealed Classes (Second Preview) (JEP 397) (tbc)
Nous avons déjà couvert records and sealed classes sur InfoQ - mais notez que la seconde preview des Sealed Classes n'est toujours pas ciblé sur Java 16, mais il est probable que ce soit le cas.
Une autre fonctionnalité destinée aux développeurs et ciblée sur Java 16 est :
- Strongly Encapsulate JDK Internals by Default (JEP 396)
Il s'agit de la prochaine étape d'un processus visant à fermer l'accès aux composants internes du JDK, afin de permettre à l'équipe de développement d'OpenJDK d'aller plus vite. Cela n'inclut pas la fameuse classe sun.misc.Unsafe, qui a été déplacée vers le module jdk.unsupported et restera disponible.
Java 16 n'est pas une version de support à long terme (LTS), il est donc peu probable qu'il soit adopté à grande échelle - sur la base du fait qu'aucune version précédente non-LTS ne l'a fait.
La prochaine version de LTS devrait être Java 17 selon la feuille de route. Celle-ci est planifiée en septembre 2021 et aucune fonctionnalité n'a encore été définitivement annoncée pour la cibler.
Cependant, le contenu de la version 16 peut nous permettre de déduire certaines choses à propos de Java 17. C'est parce que Java 16 est la dernière opportunité d'ajouter des fonctionnalités en preview ou en incubation avant la prochaine version LTS. Oracle a généralement été prudent et n'a pas fourni de nouvelles fonctionnalités majeures sans au moins un cycle de preview de la fonctionnalité.
À ce stade, rien n'indique que le projet Valhalla (ajout des inline types et ré-imaginer le modèle de données de bas niveau de la JVM) ou le projet Loom (ajout de "threads virtuels" gérés par la VM et d'un modèle de concurrence considérablement accrue) sera prêt à être livré en preview d'ici mars prochain. En conséquence, il semble assez probable que ces nouvelles initiatives ne seront pas disponibles en tant que fonctionnalités finales dans la version LTS Java 17.
Cela signifie que, pour autant que nous puissions prédire maintenant, des quatre grands projets en cours dans OpenJDK (Valhalla, Loom, Panama et Amber) - aucun d'entre eux ne sera complètement livré en septembre prochain.
Avec de la chance, nous pourrions avoir la livraison d'un bon morceau d'Amber - à la fois des records et des classes scellées en tant que fonctionnalités finales, mais le travail sur le pattern matching sera toujours très incomplet - avec seulement des switch expressions de commutation et les patterns instanceof comme fonctionnalités livrées. Certaines des JEP de Panama (en particulier la JEP 393, qui est à la troisième incubation dans Java 16) peuvent également être finalisés, mais pas tous. C'est encore en travaux et important pour la communauté, mais c'est plutôt décevant par rapport à la portée et aux promesses des projets.
Les collaborateurs d'Oracle expriment fréquemment l'opinion qu'il n'y a rien de spécial dans les versions LTS, et il s'agit simplement d'une désignation qui fait partie des activités de support d'Oracle et n'ont pas une signification plus large. C'est vrai, d'un point de vue technique, mais la situation sur le terrain n'a pas changé - très peu d'équipes sont prêtes à adopter la cadence de mise à jour forcée semestrielle des versions de Java et continuent à utiliser Java 8 et 11 - même si cela signifie abandonner Oracle en tant que fournisseur Java. Aucun indicateur n'indique que cette tendance changera en 2021.
Si Java 17 devient la prochaine version de LTS, la communauté peut décider que "la moitié vaut mieux que rien" - il aurait quelques fonctionnalités intéressantes (Class Data Sharing, JFR Streaming, Records, Switch Expressions, etc) ainsi qu'une amélioration des performances et d'autres améliorations internes. Cela pourrait finir par être une sorte de pétard mouillé - et il serait plutôt décevant d'être confronté à une autre attente de trois ans avant le prochain LTS (en supposant que le modèle établi par la majorité ne fait que mettre à niveau d'une LTS vers la LTS suivante continue) et la livraison complète des fonctionnalités qui intéressent réellement la communauté. L'adoption d'une telle version pourrait bien être lente - peut-être même plus lente que celle de Java 11.
Cependant, une autre possibilité est qu'Oracle puisse décider de changer la cadence des versions LTS et choisir de ne pas faire de Java 17 une LTS, et d'attendre à la place que d'autres fonctionnalités soient dans un état final. Par exemple, un report d'un an de LTS à 2022 (Java 19) pourrait bien donner suffisamment de temps pour livrer le reste d'Amber, Loom, davantage de Panama et peut-être même Valhalla à un état fini et livrable. Ce serait un changement dans leur feuille de route et nécessiterait une autre année d'attente, mais cela pourrait entraîner une version beaucoup plus complète et convaincante pour redynamiser la communauté et actualiser Java pour les décennies à venir.