Auparavant, les nouvelles versions de Java apparaissaient rarement et avec du retard. Désormais, Oracle maintient avec succès son rythme de « nouveau Java tous les six mois ». Il y a donc quelques jours, strictement dans les délais, nous avons enfin reçu Java SE 11 et l'implémentation du JDK (Java Development Kit). Comme toujours, la nouvelle version sera compatible avec les anciennes et le support de Java 11 prendra fin au plus tôt en décembre 2026.
Nouvelles fonctionnalités de Java SE 11 (visibles par les développeurs)
Rappelons qu'en Java, les changements s'effectuent via la mise en œuvre de la JEP « JDK Enhancement Proposal ». JEP est une proposition visant à améliorer OpenJDK et peut être approuvée, retardée ou rejetée. Autrement dit, une collection de JEP constitue essentiellement une stratégie de développement pour OpenJDK. Entre crochets avant la nouvelle « fonctionnalité » nous indiquerons le numéro de la JEP correspondante. [323] Syntaxe des variables locales pour les paramètres Lambda - syntaxe var pour les paramètres lambda Java 10 a introduit le mot-clé var, qui permettait de ne pas spécifier explicitement le type d'une variable locale. Cela a simplifié le code. JEP 323 étend l'utilisation de cette syntaxe avec des expressions lambda. Exemple simple :
Comme l' écrit Simon Ritter , un évangéliste Java bien connu, un programmeur Java expérimenté remarquera que l'utilisation de var dans ce cas peut être inutile, puisque le code ci-dessus peut être remplacé par ce qui suit :
list.stream ().map (s -> s.toLowerCase ()).collect (Collectors.toList ());
Pourquoi, alors, soutenir var ? Il n'y a qu'un seul cas particulier : lorsque vous souhaitez ajouter une annotation à un paramètre lambda. Cela ne peut pas être fait sans qu'un certain type soit impliqué, et pour éviter d'avoir à utiliser un type explicite, nous pouvons tout simplifier en utilisant var comme ceci :
[330] Lancer des programmes à code source à fichier unique Améliorer le lanceur Java pour lancer un programme sous forme de fichier unique avec le code source Java Java est souvent critiqué pour sa syntaxe verbeuse et sa « cérémonie » en plusieurs étapes de lancement, même d'une application triviale. Parfois, cela effraie les débutants. Pour écrire une application qui imprime simplement « Hello World ! » ", vous devez écrire une classe avec une voidméthode main statique publique et utiliser le System.out.println. Ceci fait, vous devez compiler le code en utilisant javac . Enfin, après cela, vous pouvez lancer l'application, qui affichera le message d'accueil malheureux (bien sûr, l'environnement de développement intégré, à la fois IDEA et celui intégré à JavaRush , effectue cette « magie du lancement d'application » de lui-même - ndlr ). Soyons honnêtes : dans la plupart des langages de programmation, le script permettant d'exécuter des programmes semble beaucoup plus simple. JEP 330 élimine le besoin de compiler une application à fichier unique, donc maintenant, si vous utilisez la ligne de commande, tapez simplement
java HelloWorld.java
Le lanceur Java détectera que le fichier contient du code source Java et compilera le code dans un fichier de classe avant de l'exécuter. Vous pouvez placer des paramètres après ou avant le nom du fichier de code source. Ceux placés après le nom sont passés en paramètres lors de l'exécution de l'application. Ceux placés avant le nom sont passés en paramètres au lanceur Java après la compilation du code. Les options spécifiques au compilateur (telles que le chemin de classe) seront également transmises à javac pour la compilation. Exemple. Doubler:
java -classpath / home / foo / java Hello.java Bonjour
sera équivalent à ces lignes :
javac -classpath / home / foo / java Hello.java
java -classpath / home / foo / java HelloBonjour
[321] Client HTTP (Standard) - La prise en charge de l'API client HTTP a été standardisée. JDK 9 a introduit une nouvelle API pour prendre en charge le protocole client HTTP (JEP 110) . Depuis que JDK 9 a également introduit le Java Platform Module System (JPMS) , cette API a été incluse en tant que module incubateur (il s'agit de modules destinés à fournir aux développeurs de nouvelles API qui ne sont pas encore devenues standard dans Java SE, tandis que les API "live" sont en cours préparé pour la suppression - les développeurs peuvent essayer de nouvelles API et essayer de fournir des commentaires). Une fois les modifications nécessaires apportées (cette API a été mise à jour dans JDK 10), l'API peut faire partie du standard. Ainsi, l'API client HTTP est désormais officiellement incluse dans Java SE 11 . Cela introduit un nouveau module et package pour le JDK, java.net.http . Les principaux nouveaux types sont : HttpClient HttpRequest HttpResponse WebSocket Cette API peut être utilisée de manière synchrone ou asynchrone. En mode asynchrone, CompletionFutureset sont utilisés CompletionStages. [320] Supprimer les modules Java EE et CORBA Avec l'introduction du Java Platform Module System (JPMS) dans la neuvième version de Java, il est devenu possible de diviser le fichier monolithique rt.jar en plusieurs modules. De plus, JPMS vous permet de créer un environnement d'exécution Java qui inclut uniquement les modules nécessaires à votre application, réduisant ainsi considérablement sa taille. Avec des limites de modules définies de manière transparente, il est beaucoup plus facile de supprimer les parties obsolètes de l'API Java - c'est ce que fait JEP 320. Le métamodule java.se.ee comprend six modules qui ne feront pas partie de la norme Java SE 11 et ne seront pas inclus. dans le JDK :
Corbeau
transaction
Activation
xml.bind
xml.ws
xml.ws.annotation
Ces modules étaient obsolètes dans JDK 9 et n'étaient pas inclus par défaut dans la compilation ou l'exécution. Cela signifie que si vous avez essayé de compiler ou d'exécuter une application qui utilise les API de ces modules sur JDK 9 ou JDK 10, cela a échoué. Si vous utilisez les API de ces modules dans votre code, vous devrez les fournir sous forme de module ou de bibliothèque distincte.
Nouvelles API
Un grand nombre de nouvelles API dans JDK 11 sont apparues grâce à l'inclusion des modules HTTP Client et Flight Recorder dans le standard de langage . Pour une liste complète des API, consultez la comparaison complète suivante des différentes versions du JDK , compilée par Gunnar Morling. Et dans cette note, nous listerons quelques nouvelles méthodes qui ne sont pas incluses dans les modules java.net.http , jdk.jfr et java.security . java.lang.String Sans doute l'un des changements les plus importants apportés à String dans l'API JDK 11, il existe plusieurs nouvelles méthodes utiles.
boolean isBlank (): renvoie true si la chaîne est vide ou ne contient que des espaces, false sinon.
Stream lines(): Renvoie un flux de lignes extraites de cette chaîne, séparées par des terminateurs de ligne.
String repeat (int): Renvoie une chaîne dont la valeur est la concaténation de cette chaîne répétée plusieurs fois.
String strip (): Renvoie une chaîne avec tous les espaces supprimés avant ou après le premier caractère autre qu'un espace.
String stripLeading (): Renvoie une chaîne avec tous les espaces jusqu'au premier caractère non-espace supprimé.
String stripTrainling (): Renvoie une chaîne avec tous les espaces qui apparaissent après la suppression du dernier caractère non-espace.
strip()La méthode a déjà fait quelque chose de similaire trim (), mais par espaces, ces méthodes signifient des choses différentes. Dans ce cas, trim()seuls les espaces sont coupés, et strip()les caractères spéciaux, tels que les tabulations, sont également inclus. java.lang.StringBuffer java.lang.StringBuilder Ces deux classes contiennent une nouvelle méthode compareTo ()qui accepte StringBuffer/ StringBuilderet renvoie int. La méthode de comparaison lexicale est similaire à la nouvelle méthode compareTo() CharSequence. java.io.ByteArrayOutputStream
void writeBytes (byte []) : écrit tous les octets du paramètre dans le flux de sortie java.io.FileReader
Il y a ici deux nouveaux constructeurs qui vous permettent de spécifier Charset. java.io.FileWriter Quatre nouveaux constructeurs qui vous permettent de spécifier Charset. java.io.InputStream
io.InputStream nullInputStream (): renvoie InputStream, qui ne lit aucun octet. Comment utiliser cette méthode ? Vous pouvez y penser comme quelque chose comme /dev/null pour supprimer la sortie dont vous n'avez pas besoin ou pour injecter une entrée qui renvoie toujours zéro octet.
java.io.OutputStream
io.OutputStream nullOutputStream ()
java.io.Reader
io.Reader nullReader ()
java.io.Writer
io.Writer nullWriter ()
java.lang.Caractère
String toString (int): Il s'agit d'une surcharge d'une méthode existante, mais utilise int au lieu de char.
java.lang.CharSequence
int compare (CharSequence, CharSequence): compare lexicographiquement deux instances CharSequence. Renvoie une valeur négative, zéro ou une valeur positive si la première séquence est lexicographiquement inférieure, égale ou supérieure à la seconde, respectivement.
java.lang.ref.Référence
lang.Object clone (): L'évangéliste Java Simon Ritter admet que cette méthode le déroute. La classe
Referencen'implémente pas d'interface
Cloneableet cette méthode lèvera toujours une exception
CloneNotSupportedException. Cependant, l'expert suggère que cette méthode sera utile pour quelque chose dans le futur.
java.lang.Runtime java.lang.System Il n'y a pas de nouvelles méthodes ici. Mentionnons simplement que la méthode runFinalizersOnExit ()a été supprimée de ces deux classes, ce qui peut entraîner des problèmes de compatibilité. java.lang.Thread Aucune méthode supplémentaire, nous mentionnerons seulement qu'elles destroy ()ont stop (Throwable)été supprimées. Cependant stop (), qui ne prend aucun argument, est toujours disponible. Veuillez garder cela à l'esprit car il peut y avoir des problèmes de compatibilité. java.nio.ByteBuffer java.nio.CharBuffer java.nio.DoubleBuffer java.nio.FloatBuffer java.nio.LongBuffer java.nio.ShortBuffer Dans toutes ces classes, les développeurs du langage ont ajouté une méthode mismatch ()qui recherche et renvoie l'index relatif du première inadéquation entre ce buffer et un buffer donné. java.nio.channels.SelectionKey
int interestOpsAnd (int)
int interestOpsOr (int)
java.nio.channels.Selector
int select (java.util.function.Consumer, long): Sélectionne et exécute une action sur les touches dont les canaux correspondants sont prêts pour les opérations d'E/S. Le paramètre long est un timeout.
int select (java.util.function.Consumer): fonctionne comme la méthode ci-dessus, mais sans le délai d'attente.
int selectNow (java.util.function.Consumer): fonctionne comme la méthode ci-dessus, sauf qu'elle est non bloquante.
java.nio.file.Fichiers
String readString (Path): lit tout le contenu d'un fichier dans une chaîne, décodant les octets en caractères à l'aide du codage UTF-8 .
String readString (Path, Charset): Fonctionne comme la méthode ci-dessus, mais décode les octets en caractères à l'aide de Charset.
Path writeString (Path, CharSequence, java.nio.file. OpenOption []): Si vous écrivez une séquence de caractères CharSequencedans un fichier, ces caractères seront codés en octets (en utilisant UTF-8 ).
Path writeString (Path, CharSequence, java.nio.file. Charset, OpenOption []): fonctionne comme la méthode ci-dessus, seuls les caractères sont codés en octets à l'aide de Charset.
java.nio.file.Path
Path(String, String[]) : renvoie le chemin, transformant une chaîne de chemin ou une séquence de chaînes qui, une fois combinées, forment une chaîne de chemin.
Chemin (net.URI) : renvoie le chemin en transformant l'URI.
java.util.Collection
Object [] toArray (java.util.function.IntFunction): Renvoie un tableau contenant tous les éléments de cette collection, en utilisant la fonction génératrice fournie pour distribuer le tableau renvoyé.
void forEach (java.util.function.Consumer): Effectue l'action spécifiée sur chaque élément Itérable jusqu'à ce que tous les éléments aient été traités ou que l'action lève une exception.
boolean removeAll (java.util.Collection): Supprime tous les éléments de cette collection qui sont également contenus dans la collection spécifiée (opération facultative).
boolean removeIf (java.util.function.Predicate): Supprime tous les éléments de cette collection qui satisfont au prédicat donné.
boolean retainAll (java.util.Collection): préserve uniquement les éléments de cette collection qui sont contenus dans la collection spécifiée (opération facultative).
java.util.concurrent.TimeUnit
long convert (java.time.Duration): Convertit la durée donnée dans cette unité.
java.util.function.Predicate
Predicate not(Predicate): renvoie un prédicat qui est la négation du prédicat donné.
boolean isEmpty (): Renvoie vrai s'il n'y a pas de valeur , faux sinon .
java.util.regex.Pattern
Predicate asMatchPredicate (): L'expert Java, Simon Ritter, pense qu'il pourrait y avoir ici un véritable joyau de l'API JDK 11. Cette méthode crée un prédicat qui vérifie si ce modèle correspond à une chaîne d'entrée donnée.
java.util.zip.Deflater
int deflate (ByteBuffer): Compresse les données d'entrée et remplit le tampon spécifié avec des données compressées.
int deflate (ByteBuffer, int): Compresse les données d'entrée et remplit le tampon spécifié avec des données compressées. Renvoie la quantité réelle de données compressées.
void setDictionary (ByteBuffer): Définit le dictionnaire donné à compresser en octets dans le tampon donné. Il s'agit d'une surcharge d'une méthode existante qui peut désormais accepter un tableau ByteBufferplutôt qu'un tableau d'octets.
void setInput (ByteBuffer): Définit les données d’entrée à compresser. C'est aussi une surcharge d'une méthode existante.
java.util.zip.Inflater
int inflate (ByteBuffer): Décompresse les octets dans le tampon spécifié. Renvoie le nombre réel d'octets non compressés.
void setDictionary (ByteBuffer): Définit le dictionnaire donné sur les octets du tampon donné. Est une forme surchargée d’une méthode existante.
void setInput (ByteBuffer): Définit les données d’entrée pour la décompression. Une forme surchargée d’une méthode existante.
javax.print.attribute.standard.DialogOwner Il s'agit d'une nouvelle classe dans JDK 11 et est une classe d'attribut utilisée pour prendre en charge les demandes d'impression ou de personnalisation de pages à afficher au-dessus de toutes les fenêtres ou d'une fenêtre spécifique. javax.swing.DefaultComboBoxModel javax.swing.DefaultListModel
void addAll (Collection): Ajoute tous les éléments présents dans la collection.
void addAll (int, Collection): Ajoute tous les éléments présents dans la collection, en commençant à l'index spécifié.
javax.swing.ListSelectionModel
int [] getSelectedIndices (): renvoie un tableau de tous les index sélectionnés dans le modèle sélectionné par ordre croissant.
int getSelectedItemsCount (): renvoie le nombre d'éléments sélectionnés.
jdk.jshell.EvalException
shell.JShellException getCause (): Renvoie la raison pouvant être lancée dans le client d'exécution présentée par cette EvalException, ou null si la raison n'existe pas ou est inconnue.
Fonctionnalités non-développeurs de Java 11
[181] Nest-Based Access Control Java et d'autres langages prennent en charge les classes imbriquées via des classes internes. Pour que cela fonctionne, le compilateur doit effectuer certaines astuces. Par exemple:
publicclassOuter{privateint outerInt;classInner{publicvoidprintOuterInt(){System.out.println("Outer int = "+ outerInt);}}}
Le compilateur modifie cela pour produire quelque chose comme ce qui suit avant de compiler :
publicclassOuter{privateint outerInt;publicint access$000(){return outerInt;}}classInner$Outer{Outer outer;publicvoidprintOuterInt(){System.out.println("Outer int = "+ outer.access$000());}}
Bien que logiquement la classe interne fasse partie du même code que la classe externe, elle est compilée en tant que classe distincte. Par conséquent, cette opération nécessite une méthode de jointure synthétique qui doit être créée par le compilateur pour donner accès au champ privé de la classe externe. Cette JEP introduit le concept de nids, où deux membres du même nid (Extérieur et Intérieur dans notre exemple) sont des copains de nidification. Deux nouveaux attributs sont définis pour le format de fichier de classe : NestHost et NestMembers . Ces modifications sont utiles pour d'autres langages prenant en charge les classes imbriquées et le bytecode. Cette fonction introduit trois nouvelles méthodes pour java.lang.Class : Class getNestHost () Class [] getNestMembers () boolean isNestmateOf (Class) [309] Constantes de fichier de classe dynamiques Ce JEP décrit une extension du format de fichier de classe pour prendre en charge le nouveau formulaire de pool persistant CONSTANT_Dynamic. L'idée d'une constante dynamique semble être un oxymore, mais vous pouvez essentiellement la considérer comme une valeur finale dans Java 11. La valeur d'une constante de pooling n'est pas définie au moment de la compilation (contrairement à d'autres constantes), mais utilise un bootstrap. méthode pour déterminer la valeur au délai de livraison. La valeur est donc dynamique, mais comme sa valeur n'est définie qu'une seule fois, elle est également constante. Cette fonctionnalité est principalement destinée aux personnes développant de nouveaux langages et compilateurs qui généreront des bytecodes et des fichiers de classe en sortie à exécuter sur la JVM. [315] Améliorer les intrinsèques d'Aarch64 Cette JEP a été proposée par la communauté Red Hat. La JVM peut désormais utiliser des instructions plus spécialisées disponibles dans le jeu d'instructions Arm 64. Cela améliore notamment les performances des méthodes , sin ()et cos ()de la log ()classe java.lang.Math . [318] Epsilon : un garbage collector sans opération Comme pour la JEP 315 , vous pouvez remercier Red Hat pour l'introduction du garbage collector Epsilon. Epsilon est inhabituel dans le sens où il ne collecte pas réellement les déchets ! Lors de la création de nouveaux objets, il alloue de la mémoire si nécessaire, mais ne récupère pas l'espace occupé par les objets non enregistrés. " À quoi ça sert? ", - tu demandes. Il s’avère que cette « collecte des déchets » a deux utilités :
Tout d'abord, ce garbage collector est conçu pour garantir que les nouveaux algorithmes GC sont évalués en termes de leur impact sur les performances. L'idée est d'exécuter un exemple d'application avec Epsilon et de générer un ensemble de métriques. Le nouvel algorithme de garbage collection est activé, les mêmes tests sont exécutés, puis les résultats sont comparés.
Pour des tâches très courtes (pensez aux fonctions sans serveur dans le cloud) où vous pouvez garantir que vous ne dépasserez pas la mémoire allouée au tas. Cela peut améliorer les performances en éliminant la surcharge (notamment la collecte des statistiques nécessaires pour décider d'exécuter ou non le collecteur) dans le code de l'application. Si l'espace du tas est épuisé, la JVM peut être mal configurée de l'une des trois manières suivantes :
La normale s'appelle OutOfMemoryError.
Effectuer une réinitialisation du tas
Le disque dur JVM est en panne et est peut-être en train d'effectuer une autre tâche (telle que le démarrage d'un débogueur).
[328] : Flight Recorder Flight Recorder est un framework d'acquisition de données de bas niveau pour la JVM. Avant JDK 11, il s'agissait d'une fonctionnalité commerciale du binaire Oracle JDK. Oracle élimine désormais les différences fonctionnelles entre le JDK Oracle et une version d'OpenJDK. Voici ce que fait Flight Recorder :
Fournit une API pour produire et consommer des données sous forme d'événements
Fournit un mécanisme de tampon et un format de données binaires
Permet la personnalisation et le filtrage des événements
Fournir des événements pour les bibliothèques OS, JVM HotSpot et JDK
Il y a deux nouveaux modules ici : jdk.jfr et jdk.management.jfr . [329] Algorithmes cryptographiques ChaCha20 et Poly1305 Cette JEP concerne la mise à jour des chiffrements utilisés par le JDK. Ce cas implémente les algorithmes de chiffrement ChaCha20 et ChaCha20-Poly1305 comme spécifié dans la RFC 7539. ChaCha20 est un chiffrement de flux relativement nouveau qui peut remplacer l'ancien chiffrement RC4 non sécurisé . [333] ZGC : Un garbage collector évolutif à faible latence Un garbage collector expérimental évolutif à faible latence. Conçu pour être utilisé avec des applications nécessitant un segment de mémoire volumineux (plusieurs gigaoctets) et une faible latence. Il utilise un tas de génération unique et effectue la plupart (mais pas la totalité) du travail de récupération de place en même temps que l'application. [332] Transport Layer Security (TLS) 1.3 TLS 1.3 (RFC 8446) est un correctif majeur du protocole de sécurité de la couche de transport TLS qui offre des améliorations significatives en matière de sécurité et de performances par rapport aux versions précédentes. Le JDK prend désormais en charge cette version du protocole. Le matériel est basé sur un article de Simon Ritter et une documentation officielle .
GO TO FULL VERSION