Les nouveautés de Java 23 : partie 2

Avec la classe Console introduite dans Java 6, il est possible d’afficher facilement du texte sur la console et lire les entrées de l’utilisateur à partir de la console.

Exemple :

Le code peut être compilé et exécuté.

Ces méthodes utilisent toujours la Locale par défaut. Selon le paramètre de langue, Pi peut être affiché soit 3.141593 (avec un point), soit 3,141593 (avec une virgule).

À partir de Java 23, il est possible de préciser une locale comme paramètre supplémentaire pour les méthodes printf(…​), format(…​), readLine(…​), et readPassword(…​).

Des surcharges de quatre méthodes ont été ajoutées à la classe java.io.Console qui attendent en argument un objet de type java.util.Locale :

Exemple

Ces méthodes permettent d’afficher une chaîne ou un prompt à la console formaté avec les paramètres régionaux spécifiés via la Locale, qui peuvent être indépendants des paramètres régionaux par défaut. Exemple :

Le code peut être compilé et exécuté.

Dans cet exemple, Pi est désormais toujours imprimé dans le style américain avec un point comme séparateur de la partie décimale.

Pour déterminer la durée entre deux objets de type Instant, il fallait auparavant utiliser la méthode Duration.between(). Exemple :

Comme cette méthode n’est pas facile à trouver, une nouvelle méthode until(Instant) a été ajoutée à la classe java.time.Instant pour obtenir la durée jusqu’à l’Instant spécifié. Cette nouvelle méthode produit la même durée que Duration.between() mais elle est plus facile à découvrir pour les utilisateurs. Exemple :

La nouvelle méthode ofPosixLiteral(String) de la classe Inet4Address crée une Inet4Address basée sur la représentation textuelle fournie d’une adresse IPv4 sous une forme compatible POSIX inet_addr.

La méthode ofPosixLiteral() implémente un algorithme d’analyse de chaîne au format POSIX inet_addr, permettant d’utiliser des segments d’adresse octal et hexadécimal. « 0 » est le préfixe des nombres octaux, « 0x » et « 0X » sont les préfixes des nombres hexadécimaux. Les segments d’adresse non nuls qui commencent à partir de chiffres non égaux à zéro sont analysés comme des nombres décimaux.

Les formes suivantes (non décimales) sont prises en charge par cette méthode :

Si la chaine de caractères fournie ne représente pas une adresse IPv4 valide au format POSIX, une exception de type IllegalArgumentException est levée.

Cette méthode ne bloque pas, car aucune recherche de nom d’hôte n’est effectuée.

Une analyse indulgente doit être utilisée lors de la tentative d’analyse d’un nombre à partir d’une chaîne contenant des valeurs non numériques ou non liées au format.

Une analyse stricte doit être utilisée lorsqu’on tente de s’assurer qu’une chaîne respecte exactement les conventions d’une Locale, et peut donc servir à valider la valeur. Par exemple :

La classe java.text.NumberFormat et ses classes filles ont vu l’ajout des méthodes setStrict(boolean) et isStrict(), qui peuvent être utilisées pour changer le mode de formatage.

La classe NumberFormat analyse par défaut avec indulgence. Les sous-classes peuvent envisager d’implémenter une analyse stricte et, en tant que telle, de redéfinir des implémentations pour les méthodes facultatives isStrict() et setStrict(boolean).

La méthode boolean isStrict() renvoie true si l’analyse est réalisée de manière stricte sinon elle retourne false. L’implémentation par défaut lève toujours une exception de type UnsupportedOperationException. Les sous-classes doivent redéfinir cette méthode lors de l’implémentation d’une analyse stricte.

La méthode void setStrict(boolean strict) permet d’indiquer si l’analyse est stricte (true) ou indulgente (false), par défaut, elle est indulgente. L’implémentation par défaut lève toujours une exception de type UnsupportedOperationException. Les sous-classes doivent redéfinir cette méthode lors de l’implémentation d’une analyse stricte.

Les implémentations de java.nio.file.WatchService mettent en mémoire tampon jusqu’à un nombre maximal d’événements avant d’ignorer les événements, et de mettre dans la file d’attente un événement OVERFLOW.

Une nouvelle propriété système, jdk.nio.file.WatchService.maxEventsPerPoll, a été ajoutée pour permettre de spécifier le nombre maximal d’événements en attente qui peuvent être mis en file d’attente avant qu’un événement OVERFLOW ne soit émis. La valeur de cette propriété doit être un entier positif.

L’objectif de la classe sun.misc.Unsafe, introduite en 2002 dans le JDK 1.4, a été de proposer des opérations de bas niveau dans et pour le JDK. Elle contient entre-autre des méthodes permettant d’accéder directement à la mémoire dans le heap et hors heap :

Comme le nom de la classe l’indique, la plupart de ces opérations ne sont pas sûres. Cependant, ces méthodes peuvent aider à augmenter les performances dans certains scénarios spécifiques, mais uniquement si des vérifications exhaustives de sécurité sont effectuées.

Malgré les risques, sun.misc.Unsafe est devenu très populaire au fil du temps par les développeurs de bibliothèques à la recherche de performances et de fonctionnalités supérieurs à ce que les API Java standard pouvaient offrir, telles que les opérations atomiques ou la gestion avancée de la mémoire hors heap.

Cependant, comme ces méthodes contournent les mécanismes de sécurité de Java : elles introduisaient des dangers potentiels tels que des plantages de la JVM et des erreurs difficiles à déboguer. L’utilisation de ces méthodes peut entraîner un comportement inattendu de l’application, une détérioration des performances ou même des blocages de la JVM. Malheureusement, de nombreuses bibliothèques utilisent sun.misc.Unsafe puisque la visibilité de cette classe est public, mais toutes n’effectuent pas les vérifications de sécurité requises.

Depuis l’introduction des modules en Java, l’objectif est de proposer des solutions de remplacement standard des fonctionnalités de Unsafe afin de ne plus permettre une utilisation de cette classe en dehors des API de Java Core du JDK.

Au fil des versions du JDK, des API standard plus sûres ont été introduites pour remplacer ces opérations :

Ces API sont intrinsèquement plus stables et fiables et doivent être utilisées à la place de sun.misc.Unsafe.

L’objectif de la JEP 471 est d’encourager les développeurs à passer d’Unsafe à ces API plus sûres et prises en charge, améliorant ainsi la compatibilité avec les futures versions du JDK tout en réduisant les risques de comportements erratiques ou de plantages.

Pour les atteindre, la JEP inclus :

Cette JEP n’a pas pour objectif de supprimer entièrement sun.misc.Unsafe, car quelques méthodes ne sont pas utilisées pour l’accès à la mémoire. Ces méthodes seront dépréciées et supprimées séparément ultérieurement.

La JEP encourage vivement les développeurs à migrer de sun.misc.Unsafe vers les remplacements pris en charge, afin que les applications puissent migrer en douceur vers les versions modernes du JDK. La grande majorité des développeurs Java n’utilisent pas explicitement sun.misc.Unsafe dans leur propre code, mais de très nombreuses applications en dépendent, directement ou indirectement à cause des nombreuses bibliothèques qui l’utilisent.

Pour permettre d’évaluer l’impact de la dépréciation et de la suppression des méthodes de sun.misc.Unsafe sur les bibliothèques en utilisant, une nouvelle option en ligne de commande de la JVM HostSpot est ajoutée : --sun-misc-unsafe-memory-access. Cette option est similaire, dans l’esprit et dans la forme, à l’option --illegal-access introduite par la JEP 261 dans le JDK 9. Plusieurs valeurs sont utilisables pour indiquer le comportement attendu :

Il est aussi possible de tracer les invocations des méthodes dépréciées de sun.misc.Unsafe en utilisant l’événement jdk.DeprecatedInvocation dans un enregistrement JFR.

La section « sun.misc.Unsafe memory-access methods and their replacements » de la JEP propose une liste complète de toutes les méthodes marquées comme obsolètes avec leurs remplacements respectifs.

Le package java.beans.beancontext a été ajouté dans la version 1.2 du JDK, bien avant les nouvelles fonctionnalités du langage telles que les annotations, les lambdas et les modules, ainsi que les paradigmes de programmation tels que « Configuration déclarative », « Injection de dépendances » et « Inversion de contrôle ».

Ce package proposait des mécanismes pour l’assemblage de composants JavaBeans hiérarchiques. Cela a permis aux composants individuels de produire et de consommer des services exprimés sous forme d’interfaces par leurs pairs, ancêtres et descendants.

Avec les évolutions du langage Java, ces API sont maintenant à la fois obsolètes et expriment un « anti-pattern » d’assemblage et d’interaction des composants. Elles seront donc dépréciés pour suppression dans une version future.

Il ne faut plus utiliser ces API et prévoir de migrer tout code existant dépendant de ce package vers une solution alternative en prévision de leur suppression future.

Pour atténuer une anomalie de planification et de préemption des green threads pouvant survenir sur le système d’exploitation Solaris, des bibliothèques inséraient des appels à Thread.yield() à de nombreux endroits pour essayer d’être de « bons citoyens ».

Avec le modèle d’ordonnancement des threads utilisé par Hotspot sur Solaris, ces appels à yield() étaient non seulement inutiles, mais devenaient également préjudiciables aux performances.

Pour atténuer cette limitation de yield(), le flag produit DontYieldALot et le flag de développement DontYieldALotInterval ont été introduit. Si DontYieldALot était true, alors les yield() deviendraient des no-ops à moins qu’il n’y ait eu quelques millisecondes depuis le dernier yield(). Le flag DontYieldALot n’était activé que sur Solaris.

25 ans plus tard et le code de la bibliothèque repose sur une planification préemptive et n’utilise pas beaucoup yield(). De plus, OpenJDK ne supporte plus Solaris et donc le flag est toujours false.

L’option est maintenant marquée comme dépréciée et sera dépréciée pour suppression dans les futures versions.

L’option -XX:+UseEmptySlotsInSupers a été dépréciée dans le JDK 23 et deviendra obsolète dans le JDK 24.

La valeur par défaut est true. Cela signifie que la JVM HotSpot allouera toujours les champs dans une super classe lors de la disposition des champs où il y a un espace aligné pour s’adapter aux champs.

Le code qui s’appuie sur la position des champs d’instance doit être conscient de ce détail de la disposition des champs d’instance. Le format de disposition des champs JVM n’est pas spécifié par les spécifications et est susceptible d’être modifié.

L’option PreserveAllAnnotations de la JVM été introduite dans le JDK 1.5 pour prendre en charge le test de code d’annotation Java et a toujours été désactivée par défaut.

Cette option est dépréciée dans le JDK 23. L’utilisation de cette option produit un avertissement.

L’option sera supprimée dans une future version, probablement dans le JDK 25.

Lorsque les notifications de débogage sont passées de l’envoi par le « Service Thread » masqué au « Notification Thread » non masqué, cette option a été fournie (par défaut à true) afin qu’elle puisse être désactivée en cas de problème lors de l’utilisation du « Notification Thread ». Comme aucun problème n’a été signalé, le « Notification Thread » va devenir le seul moyen d’envoyer des notifications à l’avenir, et l’option ne sera plus disponible.

L’option UseNotificationThread de la JVM est dépréciée. Elle sera supprimée dans une future version du JDK.

Les String templates, qui étaient proposés en preview dans les JDK 21 et JDK 22, ont été retirés dans le JDK 23.

Cette fonctionnalité était destinée à compléter les chaînes littérales et les blocs de texte de Java en couplant du texte littéral et des expressions intégrées pour réaliser une interpolation de manière potentiellement sûre afin de produire des chaînes de caractères ou une instance quelconque.

La communauté OpenJDK a estimé que la capacité « ne faisait pas sa part » et que d’autres évaluations et une potentielle refonte prendraient du temps. 

Il est à noter que c’est la première fois qu’une fonctionnalité en preview n’est pas reconduite dans une version suivante du JDK.

La JEP 12, qui définit le processus de mise en œuvre des fonctionnalités en preview :

une fonctionnalité en preview est spécifique pour une version du JDK, et donc si une fonctionnalité n’est pas reconduite en preview ou promue en standard, elle doit être retirée * elle indique clairement qu’une fonctionnalité en preview peut être supprimée, sans qu’il soit nécessaire d’en créer une nouvelle

Une refonte globale de cette fonctionnalité va être effectuée, car elle avait suscité de nombreux débats et ne semblait pas répondre aux attentes de la communauté.

Le VarHandle retourné par MethodHandles::byteArrayViewVarHandle ne prend plus en charge les modes d’accès atomiques, et le VarHandle retourné par MethodHandles::byteBufferViewVarHandle ne prend plus en charge les modes d’accès atomiques lors de l’accès aux tampons dans le heap.

De plus, les méthodes ByteBuffer::alignedSlice et ByteBuffer::alignmentOffset sont mises à jour pour refléter ces modifications. Elles ne signalent plus les tranches alignées ou les décalages pour les tampons d’octets dans le heap lorsque la valeur unitSize consultée est supérieure à 1. Dans ce cas, elles lèvent une exception UnsupportedOperationException.

La fonctionnalité supprimée était basée sur un détail d’implémentation dans la JVM de référence qui n’est pas imposée par les spécifications de la JVM. Par conséquent, il n’est pas garanti de fonctionner sur l’implémentation d’une autre JVM. Cela permet également à l’implémentation de référence d’aligner plus librement les éléments du tableau, si cela est jugé bénéfique.

Les utilisateurs concernés doivent envisager d’utiliser des tampons d’octets directs (off heap), pour lesquels un accès aligné peut être garanti de manière fiable. Ou ils devraient utiliser un long[] pour stocker leurs données, qui a des garanties d’alignement plus fortes que byte[]. Un MemorySegment lié à un tableau long[] est accessible via un mode d’accès atomique et n’importe quel type primitif, en utilisant l’API Foreign Function & Memory. Exemple :

Depuis Java 1.2, la méthode ThreadGroup.stop() était marquée comme dépréciée, car le concept d’arrêt d’un groupe de threads était mal implémenté dès le départ.

Dans le JDK 16, la méthode a été déclarée dépréciée pour suppression.

Depuis le JDK 19, la méthode ThreadGroup.stop() lève une exception de type UnsupportedOperationException

Cette méthode est finalement supprimée dans le JDK 23 :

Les méthodes Thread.suspend(), Thread.resume(), ThreadGroup.suspend() et ThreadGroup.resume() sont dépréciées depuis le JDK 1.2 car elles pouvaient engendrer des deadlocks.

Dans le JDK 14, ces méthodes ont été dépréciées pour suppressions (deprecated for removal).

Dans le JDK 19, les méthodes suspend() et resume() de la classe ThreadGroup lèvent une exception de type UnsupportedOperationException.

Dans le JDK 20, les méthodes suspend() et resume() de la classe Thread font de même.

Dans le JDK 23, toutes ces méthodes ont été retirées :

Le module jdk.random a été supprimé du JDK. Ce module contenait les implémentations des algorithmes java.util.random.RandomGenerator. Ces implémentations ont été déplacées vers le module java.base qui est désormais responsable de la prise en charge de ces algorithmes.

Si un module utilise une clause requires jdk.random alors, il faut la supprimer pour permettre sa compilation en Java 23 puisque le module jdk.random est supprimé et que le module java.base est automatiquement requis.

Les données locales JRE héritées ont été supprimées du JDK. Les données de paramètres régionaux JRE héritées, dont COMPAT est un alias pour ces données de paramètres régionaux, sont restées après que les données de paramètres régionaux CLDR basées sur le Common Locale Data Registry du Consortium Unicode soient devenues la valeur par défaut avec JDK 9 (JEP 252).

Les données locales JRE ont servi d’outil pour migrer les applications pour le moment. Depuis le JDK 21, les utilisateurs ont été informés de sa suppression future par un message d’avertissement au démarrage, car l’utilisation des données locales JRE/COMPAT était obsolète.

Elles sont maintenant supprimées du JDK 23, de sorte que la spécification de JRE ou COMPAT dans la propriété système java.locale.providers n’a plus aucun effet. Les applications utilisant des données locales JRE/COMPAT sont encouragées à migrer vers les données locales CLDR ou à envisager une solution de contournement décrite dans la JDK-8325568.

JEP 252: Use CLDR Locale Data by Default a été mis à jour avec des recommandations pour les développeurs impactés par la suppression de ces données de paramètres régionaux héritées.

Afin de préparer la plate-forme à la suppression du Security Manager, la fonctionnalité JMX (Java Management Extensions) « Subject Delegation » a été supprimée dans le JDK 23.

La méthode getMBeanServerConnection(Subject delegationSubject) de la classe javax.management.remote.JMXConnector lève désormais une exception de type UnsupportedOperationException si elle est appelée avec un Subject de délégation non null.

Si une application cliente doit effectuer des opérations avec plusieurs identités ou pour le compte de celles-ci, elle devra désormais effectuer plusieurs appels à JMXConnectorFactory.connect() et à la méthode getMBeanServerConnection() sur le JMXConnector renvoyé.

Pour plus d’informations, consultez la section Security du tutoriel JMX.

Pour préparer la plate-forme à la suppression du Security manager, la fonctionnalité m-let de JMX a été supprimée. Cette suppression n’a aucun impact sur l’agent JMX utilisé pour la surveillance locale et à distance, l’instrumentation intégrée de la machine virtuelle Java ou les outils qui utilisent JMX.

Les classes de l’API qui ont été supprimées sont :

L’option RegisterFinalizersAtInit de la JVM HotSpot, dépréciée dans le JDK 22, a été rendue obsolète dans cette version.

L’option -Xnoagent de la JVM HotSpot, qui a été dépréciée pour la suppression dans une version précédente, a maintenant été supprimée.

Le lancement de la JVM avec cette option entraînera désormais une erreur et le processus ne sera pas lancé.

Les applications qui utilisent cette option lors du lancement de la commande java doivent la supprimer.