Le JDK 18 est déjà en cours de développement et l'équipe vient de livrer un aperçu des nouveautés dans cette nouvelle mouture du kit de développement Java, dont la sortie est prévue pour le 22 mars 2022. Java 18 sera livré avec une API pour les vecteurs, un deuxième aperçu de la correspondance des motifs pour les instructions switch, l'UTF-8 comme jeu de caractères par défaut et d'un serveur Web minimal. Une version préliminaire devrait être disponible en janvier prochain et les versions candidates (RC) sont prévues pour le 10 et 24 février 2022.Alors que le JDK 17 était une version de support à long terme (LTS) qui bénéficiera d'au moins huit ans de support de la part d'Oracle, le JDK 18 sera une version de fonctionnalité à court terme qui sera supportée pendant six mois. Les premières versions du JDK 18 sont disponibles pour Linux, Windows et macOS sur java.net. Les propositions spécifiques du JDK 18 sont les suivantes :
Dépréciation de la finalisation pour une suppression dans une version future
Selon l'équipe du JDK, Finalizer a des défauts qui causent des problèmes importants dans le monde réel en matière de sécurité, de performance, de fiabilité et de maintenabilité. Il a également un modèle de programmation difficile. La finalisation est activée par défaut pour le moment, mais peut être désactivée pour faciliter les premiers tests. Elle sera désactivée par défaut dans une version de fonctionnalité et supprimée complètement dans une version ultérieure. La proposition prévoit une option de ligne de commande pour désactiver la finalisation et la dépréciation de tous les finaliseurs et méthodes de finalisation dans l'API Java standard.
Les objectifs de la proposition sont d'aider les développeurs à comprendre les dangers de la finalisation, de les préparer à sa suppression éventuelle et de fournir des outils simples pour aider à détecter la dépendance à la finalisation. Introduite dans Java 1.0, la finalisation avait pour but d'éviter les fuites de ressources. Une classe peut déclarer un finaliseur - la méthode protected void finalize() - dont le corps libère toute ressource sous-jacente. Le ramasseur de déchets planifiera l'appel du finaliseur d'un objet inaccessible avant de récupérer la mémoire de l'objet.
À son tour, la méthode finalize() peut prendre des mesures telles que l'appel de la fermeture de l'objet. Cela semble être un filet de sécurité efficace pour éviter les fuites de ressources, mais il existe des failles, notamment une latence imprévisible, avec un long délai entre le moment où un objet devient inaccessible et celui où son finaliseur est appelé ; un comportement non contraint, le code du finaliseur pouvant effectuer n'importe quelle action, y compris ressusciter un objet et le rendre à nouveau accessible ; le finaliseur est toujours activé, sans mécanisme d'enregistrement explicite.
Et les finaliseurs peuvent s'exécuter sur des threads non spécifiés dans un ordre arbitraire. Compte tenu des problèmes posés par la finalisation, il est conseillé aux développeurs d'utiliser des techniques alternatives pour éviter les fuites de ressources, à savoir les instructions try-with-resources et les nettoyeurs.
Proposition d'un SPI de résolution d'adresse Internet
La proposition consiste à définir un SPI (service-provider interface) pour la résolution d'adresses d'hôtes et de noms afin que Inet.Address puisse utiliser des résolveurs autres que le résolveur intégré à la plateforme. Les motivations de cet effort comprennent une meilleure mise en œuvre du projet Loom, pour la concurrence et les nouveaux modèles de programmation en Java, ainsi que l'intégration de nouveaux protocoles de réseau, la personnalisation et la possibilité d'effectuer des tests. La proposition n'implique pas le développement d'un autre résolveur pour le JDK.
Nouvel aperçu de la correspondance des motifs pour switch
Un deuxième aperçu de la correspondance des motifs, dans lequel le langage Java serait amélioré par la correspondance des motifs pour les expressions et les instructions switch, ainsi que par des extensions au langage des motifs. Ce projet a été présenté en avant-première dans le JDK 17. L'extension de la correspondance des motifs à switch permet de tester une expression par rapport à un certain nombre de motifs, 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.
Réimplémentation de Core Reflection avec des descripteurs de méthode
Selon l'équipe, la réimplémentation de Core Reflection avec des descripteurs de méthode réimplémenterait lang.reflect.Method, Constructor et Field au-dessus des descripteurs de méthode java.lang.invoke. Le fait que les descripteurs de méthode servent de mécanisme sous-jacent à la réflexion réduira les coûts de maintenance et de développement des API java.lang.reflect et java.lang.invoke.
Introduction d'un serveur Web minimal
Avec la proposition de serveur Web simple, un outil en ligne de commande serait fourni pour démarrer un serveur Web minimal qui ne sert que des fichiers statiques. L'équipe a expliqué qu'aucune fonctionnalité de type CGI ou servlet n'est disponible. L'outil sera utile pour le prototypage, le codage ad-hoc et les tests, en particulier dans les contextes éducatifs.
Les objectifs du plan consistent à offrir un serveur de fichiers HTTP statiques prêt à l'emploi, facile à configurer et doté d'un minimum de fonctionnalités, à réduire l'énergie d'activation des développeurs et à rendre le JDK plus accessible, ainsi qu'à fournir une implémentation par défaut via la ligne de commande et une petite API pour la création et la personnalisation programmatiques. La fourniture d'un serveur riche en fonctionnalités ou de qualité commerciale n'est pas un objectif de la proposition.
Une API de fonction étrangère et de mémoire (deuxième incubateur)
Une deuxième incubation d'une fonction étrangère et d'une API de mémoire, dans laquelle une API est introduite par laquelle les programmes Java peuvent interagir avec le code et les données en dehors du runtime Java. En invoquant des fonctions étrangères - code extérieur à la JVM - et en accédant en toute sécurité à la mémoire étrangère - 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 danger de la JNI (Java Native Interface). L'objectif est de remplacer la JNI par un modèle de développement supérieur, purement Java.
Cette API a été incubée dans le JDK 17. Pour le JDK 18, des améliorations seraient incorporées, sur la base des commentaires, telles que la prise en charge d'un plus grand nombre de supports tels que Boolean et MemoryAddress dans les descripteurs var d'accès à la mémoire, et une nouvelle API pour copier des tableaux Java vers et depuis des segments de mémoire.
Proposition d'une API pour exprimer des calculs vectoriels
L'API vectorielle sera incubée pour la troisième fois dans le JDK 18, après avoir été incubée dans les JDK 16 et JDK 17. Cette proposition exprimerait des calculs vectoriels qui seraient compilés au moment de l'exécution en instructions vectorielles optimales sur les architectures de CPU prises en charge, ce qui permettrait d'obtenir des performances supérieures aux calculs scalaires équivalents. Les opérations vectorielles expriment un degré de parallélisation qui permet d'effectuer plus de travail sur un seul cycle de l'unité centrale, ce qui améliore considérablement les performances.
L'API vectorielle indépendante de la plateforme vise à fournir un moyen d'écrire des algorithmes complexes en Java, en utilisant l'autovectoriser HotSpot existant, mais avec un modèle utilisateur qui rend la vectorisation plus prévisible. Le JDK 18 ajoutera également la prise en charge de la plateforme ARM Scalar Vector Extension et améliorera les performances des opérations vectorielles qui acceptent des masques sur les architectures qui prennent en charge le masquage dans le matériel.
Utilisation d'UTF-8 comme jeu de caractères par défaut des API standards
UTF-8 est un codage de caractères à largeur variable pour la communication électronique et est considéré comme le jeu de caractères standard du Web. Le jeu de caractères est un codage de caractères capable de coder tous les caractères du Web. Grâce à ce changement, les API qui dépendent du jeu de caractères par défaut se comporteront de manière cohérente dans toutes les implémentations locales et configurations.
La proposition ne vise pas à définir de nouvelles API standard Java ou spécifiques au JDK. Les partisans de la proposition s'attendent à ce que les applications dans de nombreux environnements ne voient aucun impact du choix d'UTF-8 par Java, car macOS, de nombreuses distributions Linux et de nombreuses applications serveur prennent déjà en charge UTF-8.
Cependant, il existe un risque dans d'autres environnements, le plus évident étant que les applications dépendant du jeu de caractères par défaut se comporteront de manière incorrecte lors du traitement de données produites lorsque le jeu de caractères par défaut n'a pas été spécifié. Une corruption des données peut se produire silencieusement. On s'attend à ce que l'impact principal tombe sur les utilisateurs de systèmes Windows dans les localités asiatiques et éventuellement sur certains environnements de serveurs dans les localités asiatiques et autres.
Source : JDK 18
Et vous ?
Quel est votre avis sur le sujet ? Que pensez-vous des nouveautés introduites par le JDK 18 ? Selon vous, pourquoi l'adoption des versions récentes de Java (JDK) est-elle lente ? Comment expliquer le fait que beaucoup de développeurs utilisent toujours Java 14, Java 11 et même Java 8 ? La migration vers les versions récentes de Java est-elle aussi difficile ? N'y a-t-il pas des risques de continuer à utiliser d'anciennes versions de Java malgré les nouvelles versions LTS ?Voir aussi
Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK Sondage : quelle édition du JDK (Java Development Kit) utilisez-vous ? Et quelles sont les raisons de votre choix ?