Java 17, dans sa version LTS (long-term support), est désormais disponible pour une utilisation en production. Oracle a également annoncé que les versions LTS, qui bénéficient d'au moins huit ans de support produit, arriveront désormais tous les deux ans, contre trois ans auparavant. Les versions non LTS bénéficient de six mois de support de la part de l’éditeur. Parmi les fonctionnalités de la version standard de Java, citons la prise en charge des filtres de désérialisation spécifiques au contexte, qui constitue une amélioration de la sécurité, et un aperçu de la correspondance des motifs pour les instructions de commutation. Le JDK 17 comprend tout ce qui a été ajouté depuis la dernière version LTS, le JDK 11, arrivé il y a trois ans. Des versions LTS plus fréquentes permettront un accès plus rapide aux dernières fonctionnalités pour les entreprises qui souhaitent simplement utiliser les versions LTS, a déclaré Georges Saab, vice-président du groupe de la plate-forme Java chez Oracle. La prochaine version LTS sera la Java 21 en 2023. Avec JDK 17, Oracle autorisera l'utilisation gratuite des binaires Oracle JDK en production pendant trois ans, soit un an après la prochaine version LTS. Mais cela n'inclut pas un abonnement au support de production de l'entreprise.   

Les données provenant de la base de clients du fournisseur de surveillance des applications New Relic, représentant des dizaines de millions de JVM de production, montrent que les versions LTS font l'objet d'un déploiement quasi unanime. New Relic a constaté que près de 100 % des utilisateurs exécutent soit JDK 11, soit JDK 8, les deux versions LTS les plus récentes. Selon New Relic, 90 % des utilisateurs utilisent le JDK 11 et 10 % le JDK 8. Cependant, Oracle a déclaré que les téléchargements des versions semestrielles ont augmenté de façon constante. Les développeurs aiment essayer les versions semestrielles tandis que les entreprises veulent déployer les versions LTS. Les versions de production du JDK 17 sont disponibles sur oracle.com. Des versions open source d'OpenJDK sont également disponibles chez l’éditeur. Les nouvelles fonctionnalités du JDK 17 sont les suivantes :  

Les principales modifications du JDK 17  

Les filtres de désérialisation spécifiques au contexte permettent aux applications de configurer des filtres de désérialisation spécifiques au contexte et sélectionnés dynamiquement via une fabrique de filtres à l'échelle de la JVM invoquée pour sélectionner un filtre pour chaque opération de sérialisation. En expliquant la motivation de cette proposition, Oracle a déclaré que la désérialisation de données non fiables est une activité intrinsèquement dangereuse, car le contenu des flux de données entrants détermine les objets qui sont créés, les valeurs de leurs champs et les références entre eux. Dans de nombreuses utilisations, les octets du flux sont reçus d'un client inconnu, non fiable ou non authentifié. En construisant soigneusement le flux, un cyberpirate peut faire en sorte que du code dans des classes arbitraires soit exécuté avec une intention malveillante. Si la construction d'un objet a des effets secondaires qui modifient l'état ou appellent d'autres actions, celles-ci peuvent compromettre l'intégrité des objets de l'application, des objets de la bibliothèque et du runtime Java. La clef pour neutraliser les attaques par sérialisation est d'empêcher les instances de classes arbitraires d'être désérialisées, empêchant ainsi l'exécution directe ou indirecte de leurs méthodes. Les filtres de désérialisation ont été introduits dans Java 9 pour permettre au code des applications et des bibliothèques de valider les flux de données entrants avant de les désérialiser. Ce code fournit une logique de validation sous la forme d'un java.io.ObjectInputFilter lorsqu'il crée un flux de désérialisation. Cependant, le fait de s'appuyer sur le créateur d'un flux pour demander explicitement la validation présente des limites. La proposition d'amélioration 290 du JDK a abordé ces limites en introduisant un filtre de désérialisation à l'échelle de la JVM qui peut être défini via une API, des propriétés système ou des propriétés de sécurité. Cependant, cette approche a également des limites, en particulier dans les applications complexes. Une meilleure approche consiste à configurer des filtres par flux de telle sorte qu'ils ne nécessitent pas la participation de chaque créateur de flux. L'amélioration prévue devrait aider les développeurs à construire et à appliquer des filtres appropriés pour chaque contexte de désérialisation et chaque cas d'utilisation. 

Avec la restauration de la sémantique de la virgule flottante toujours stricte, les opérations en virgule flottante seront rendues systématiquement strictes, plutôt que d'avoir à la fois une sémantique de la virgule flottante stricte (strictfp) et une sémantique de la virgule flottante par défaut subtilement différente. Cela rétablit la sémantique originale de la virgule flottante dans le langage et la VM, correspondant à la sémantique avant l'introduction des modes de virgule flottante stricte et par défaut dans Java Standard Edition 1.2. Cet effort a notamment pour but de faciliter le développement de bibliothèques sensibles aux nombres, dont java.lang.Math et java.lang.StrictMath. La modification de la sémantique par défaut de la virgule flottante, à la fin des années 90, est née d'une mauvaise interaction entre la sémantique originale du langage Java et de la JVM et certaines particularités du jeu d'instructions du coprocesseur à virgule flottante x87 de la célèbre architecture x86. Faire correspondre la sémantique exacte de la virgule flottante dans tous les cas, y compris les opérandes et les résultats subnormaux, nécessitait d'importantes surcharges d'instructions supplémentaires. Faire correspondre les résultats en l'absence de débordement ou d'underflow pouvait être fait avec moins de surcharge et c'est à peu près ce que permet la sémantique par défaut révisée de la virgule flottante introduite dans Java SE 1.2. Mais les extensions SSE2 (Streaming SIMD Extensions 2), livrées dans les processeurs Pentium 4 et suivants à partir de 2001, pouvaient prendre en charge les opérations en virgule flottante strictes de la JVM de manière directe et sans surcharge excessive. Depuis qu'Intel et AMD prennent en charge SSE2 et les extensions ultérieures qui permettent la prise en charge naturelle de la sémantique de la virgule flottante stricte, la motivation technique pour avoir une sémantique de la virgule flottante par défaut différente de stricte n'existe plus.  

Dépréciation du Security Manager, en vue de sa suppression dans une prochaine version. Depuis Java 1.0, Security Manager a été le principal moyen de sécuriser le code Java côté client et a rarement été utilisé pour sécuriser le code côté serveur. L'un des objectifs de la proposition est d'évaluer si de nouvelles API ou de nouveaux mécanismes sont nécessaires pour répondre à des cas d'utilisation spécifiques et étroits pour lesquels Security Manager a été utilisé, comme le blocage de System::exit. Les plans prévoient la dépréciation du gestionnaire de sécurité en vue de son retrait, de concert avec l'ancienne API Applet, dont la dépréciation est également prévue dans le JDK 17. 

Un aperçu de la correspondance des motifs pour switch étend le langage des motifs en Java pour permettre aux expressions et aux instructions switch d'être testées par rapport à un certain nombre de motifs, chacun avec une action spécifique. Cela permet d'exprimer de manière concise et sûre des requêtes complexes orientées données. Parmi les objectifs de cette fonctionnalité, citons l'élargissement de l'expressivité et de l'application des expressions et des instructions switch en permettant aux motifs d'apparaître dans les étiquettes de cas, l'assouplissement de l'hostilité historique nulle de switch lorsque cela est souhaité, et l'introduction de deux types de motifs : les motifs gardés, qui permettent à la logique de correspondance des motifs d'être affinée avec des expressions booléennes arbitraires, et les motifs entre parenthèses, qui résolvent certaines ambiguïtés d'analyse. Dans le JDK 16, l'opérateur instanceof a été étendu pour prendre un motif de type et effectuer un filtrage de motifs. L'extension modeste proposée permet de simplifier l'idiome familier instanceof-and-cast. 

L'encapsulation forte pour les éléments internes du JDK, à l'exception des API internes critiques telles que sun.misc.Unsafe, ferait qu'il ne serait plus possible de relâcher l'encapsulation forte des éléments internes via une seule option de ligne de commande, comme cela était possible dans les JDK 9 à 16. Les objectifs du plan sont d'améliorer la sécurité et la maintenabilité du JDK et d'encourager les développeurs à migrer des éléments internes vers les API standard. 

Suppression du mécanisme d'activation de l'invocation de méthode à distance (RMI) tout en conservant le reste de RMI. Le mécanisme d'activation RMI est obsolète et désuet et a été déprécié pour être supprimé dans le JDK 15. 

L'API de fonctions et de mémoires étrangères, introduite au stade de l'incubateur, permet aux programmes Java d'interagir avec du code et des données extérieures au runtime Java. En invoquant efficacement des fonctions étrangères, c'est-à-dire du code extérieur à la JVM, et en accédant en toute sécurité à la mémoire externe, c'est-à-dire à la mémoire non gérée par la JVM, l'API permet aux programmes Java d'appeler des bibliothèques natives et de traiter des données natives sans la fragilité et le risque de la JNI (Java Native Interface). L'API proposée est l'évolution de deux API : l'API d'accès à la mémoire et l'API de linker externes. L'API d'accès à la mémoire externe était destinée à Java 14 en 2019 en tant qu'API d'incubation et a été réincubée dans Java 15 et Java 16. L'API d'éditeur de liens externes était destinée à Java 16 en tant qu'API d'incubation à la fin de l'année 2020. Les objectifs du plan d'API sont la facilité d'utilisation, les performances, la généralité et la sécurité. 

Intégrée au JDK 16 en tant qu'API d'incubation, l'API vectorielle agnostique sera à nouveau incubée dans le JDK 17, fournissant un mécanisme pour exprimer les calculs vectoriels qui sont compilés de manière fiable au moment de l'exécution en instructions vectorielles optimales sur les architectures CPU prises en charge. Cela permet d'obtenir de meilleures performances que des calculs scalaires équivalents. Dans le JDK 17, l'API vectorielle a été améliorée en termes de performances et d'implémentation, notamment pour traduire les vecteurs d'octets en tableaux booléens ou à partir de ceux-ci. 

Les classes et interfaces scellées limitent les autres classes ou interfaces qui peuvent les étendre ou les mettre en œuvre. Les objectifs de la proposition sont les suivants : permettre à l'auteur d'une classe ou d'une interface de contrôler quel code est responsable de son implémentation, fournir un moyen plus déclaratif que les modificateurs d'accès pour restreindre l'utilisation d'une superclasse, et soutenir les orientations futures en matière de filtrage de motifs en fournissant une base pour l'analyse exhaustive des motifs. Cette capacité aide les concepteurs d'API à construire un code plus résistant. 

Suppression du compilateur expérimental AOT et JIT, qui a été peu utilisé mais nécessite un effort de maintenance important. Le plan prévoit de maintenir l'interface du compilateur JVM au niveau Java afin que les développeurs puissent continuer à utiliser des versions du compilateur construites en externe pour la compilation JIT. La compilation AOT (l'outil jaotc) a été intégrée au JDK 9 en tant que fonctionnalité expérimentale. Cet outil utilise le compilateur Graal, qui est lui-même écrit en Java, pour la compilation AOT. Ces fonctionnalités n'ont pas été incluses dans les builds du JDK 16 publiés par Oracle et personne ne s'en est plaint. Selon le plan prescrit, trois modules JDK seraient supprimés : jdk.aot (l'outil jaotc) ; internal.vm.compiler, le compilateur Graal ; et jdk.internal.vm.compiler.management, le MBean Graal. Le code HotSpot lié à la compilation AOT serait également supprimé. 

Portage du JDK sur MacOS/AArch64 en réponse au projet d'Apple de faire passer ses Mac de x64 à AArch64. Un portage AArch64 de Java existe déjà pour Linux et des travaux sont en cours pour Windows. Les développeurs Java s'attendent à réutiliser le code AArch64 existant de ces ports en employant la compilation conditionnelle, comme c'est la norme dans les ports du JDK, pour tenir compte des différences dans les conventions de bas niveau telles que l'interface binaire de l'application et l'ensemble des registres réservés du processeur. Les changements pour MacOS/AArch64 risquent de casser les ports existants de Linux/AArch64, Windows/AArch64, et MacOS/x64, mais le risque sera réduit par des tests de pré-intégration. 

Dépréciation de l'API Applet pour suppression. Cette API est désormais inutile, puisque tous les fournisseurs de navigateurs Web ont supprimé la prise en charge des plug-ins de navigateur Java ou ont annoncé leur intention de le faire. L'API Applet a été précédemment dépréciée, mais pas au point d’être supprimée, dans Java 9 en septembre 2017. 

Un nouveau pipeline de rendu pour MacOS, utilisant l'API Apple Metal comme alternative au pipeline existant qui utilise l'API OpenGL dépréciée. Cette proposition vise à fournir un pipeline de rendu entièrement fonctionnel pour l'API Java 2D qui utilise le cadre Metal de MacOS, afin d’être prêt au cas où Apple supprimerait l'API OpenGL d'une future version de MacOS. Le pipeline devrait avoir une parité fonctionnelle avec le pipeline OpenGL existant, avec des performances aussi bonnes ou même meilleures dans certaines applications et benchmarks. Une architecture propre serait créée et s'intégrerait dans le modèle Java 2D actuel. Le pipeline coexisterait avec le pipeline OpenGL jusqu'à son obsolescence. L'objectif de la proposition n'est pas d'ajouter d'autres API Java ou JDK. 

Générateurs de nombres pseudo-aléatoires améliorés qui fourniraient de nouveaux types d'interfaces et d'implémentations pour les générateurs de nombres pseudo-aléatoires (PRNG), y compris les PRNG sautables et une classe supplémentaire d'algorithmes PRNG divisibles (LXM). Une interface, RandomGenerator, fournira une API uniforme pour tous les PRNG existants et nouveaux. Quatre interfaces RandomGenerator spécialisées seront fournies. Ce plan est motivé par l'accent mis sur de nombreux domaines à améliorer dans le domaine de la génération de nombres pseudo-aléatoires en Java. L'effort ne prévoit pas de fournir des implémentations de nombreux autres algorithmes PRNG. Mais trois algorithmes communs ont été ajoutés et sont déjà largement déployés dans d'autres environnements de langage de programmation.