JDK 18 : les nouvelles fonctionnalités de Java 18 incluent une API pour les vecteurs, un serveur Web minimal

Et l'adoption d'UTF-8 comme jeu de caractères par défaut

JDK 18 : les nouvelles fonctionnalités de Java 18 incluent une API pour les vecteurs, un serveur Web minimal
et l'adoption d'UTF-8 comme jeu de caractères par défaut

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...