Les problèmes du monde sont les problèmes du monde, et le nouveau Java respecte le calendrier prévu. C'est-à-dire exactement une fois tous les six mois. La version finale de Java 14 a été publiée le 17 mars et a introduit plusieurs innovations intéressantes dans le langage destinées aux développeurs. Parmi eux figurent la prise en charge expérimentale du mot-clé record , la prise en charge de la correspondance de modèles dans l'opérateur " instanceof ", des NullPointerExceptions plus conviviales , une « prévisualisation » étendue des blocs de texte , un commutateur par défaut mis à jour et bien plus encore. Rappelons que toutes les innovations en Java commencent par des propositions d'extension ( JEP, Java Enhancement Proposals ). Les développeurs proposent des modifications, elles sont examinées par les parents Java « officiels », puis certaines de ces modifications sont acceptées, après quoi elles font partie du JDK. Et maintenant - tout est en ordre.
Les enregistrements, également appelés Records, sont disponibles pour JDK 14 en mode aperçu, et c'est quelque chose de complètement nouveau pour Java. En fait, nous avons devant nous un nouveau type qui a été développé lors du projet Valhalla . Les enregistrements sont similaires aux énumérations et vous permettent de simplifier votre code. Essentiellement, ils remplacent les classes qui ont un état mais aucun comportement. En termes simples, il y a des champs, pas de méthodes. Dans le cas des classes, on est parfois amené à écrire beaucoup de code répétitif qui n'est pas toujours nécessaire : constructeurs, accesseurs, equals(), hashCode(), toString(), etc. Pour éviter ce code répétitif, Java prévoit pour utiliser l'enregistrement. Voici la version classique :
C'est tout. Veuillez noter que les enregistrements existent actuellement sous forme d'aperçu, donc pour les essayer en pratique, vous devez télécharger jdk14 et saisir la commande :
javac —enable-preview —release 14Triangle.java
Les enregistrements sont des classes, mais avec des limites. Ils ne peuvent pas étendre d'autres classes ou déclarer des champs (sauf private final qui correspondent aux composants de déclaration d'état). Les enregistrements sont implicitement définitifs et ne peuvent pas être abstraits. Les enregistrements diffèrent des classes normales dans le sens où ils ne peuvent pas séparer leur API de sa représentation. Mais la perte de liberté est compensée par une précision accrue. Les composants d'enregistrement sont également implicitement définitifs.
La fonctionnalité Pattern Matching , introduite dans Java 14 en avant-première, est conçue pour combiner la vérification du type d'un objet et sa conversion dans l'opérateur instanceof . Autrement dit, avant Java 14 il y aurait eu par exemple le code suivant :
Comme vous pouvez le voir, nous devons convertir l'objet en classe dont nous voulons utiliser les méthodes. Désormais, Java 14 et la fonctionnalité Pattern Matching connectée vous permettent de réduire le code à ce qui suit :
JDK 8 disposait d'un outil javapackager conçu pour JavaFX. Cependant, suite à la séparation de JavaFX de Java avec la sortie du JDK 11, le populaire javapackager n'était plus disponible. Javapackager était un outil de packaging. Cela permettait aux applications Java d'être packagées de telle manière qu'elles puissent être installées comme tous les autres programmes « normaux ». Par exemple, créez des fichiers exe pour les utilisateurs Windows et lancez une application Java comme un humain – avec un double clic. Bien entendu, un tel outil fait cruellement défaut, c'est pourquoi le JEP 343 a introduit un nouvel outil, jpackage , qui regroupe une application Java dans un package spécifique à la plate-forme contenant toutes les dépendances nécessaires. Formats de packages pris en charge pour une plate-forme spécifique :
JEP 345 sert uniquement à implémenter la prise en charge de NUMA (accès mémoire non uniforme). Il s'agit d'architectures d'accès mémoire hétérogènes, une manière de constituer un cluster de microprocesseurs dans un système multiprocesseur dans lequel la mémoire peut être distribuée localement : chaque cœur de processeur obtient une petite quantité de mémoire locale, tandis que d'autres cœurs y ont accès. Le JEP 345 prévoit d'équiper le ramasse-miettes G1 de la capacité d'exploiter de telles architectures. Cette approche permet entre autres d’améliorer les performances sur des machines très puissantes.
Java Flight Recorder (JFR) fait désormais partie d'OpenJDK et est donc disponible gratuitement. JDK 14 ajoute une API de suivi à la volée des événements JFR (JDK Flight Recorder), notamment pour organiser une surveillance continue des applications actives et inactives. Les mêmes événements sont enregistrés que pour l'option sans streaming, avec un surcoût inférieur à 1 %. De cette façon, les événements seront diffusés en même temps que l'option sans streaming. Cependant, JEP 349 ne doit pas autoriser les rappels synchrones pour le consommateur correspondant. Même les données des enregistrements stockés dans la mémoire intermédiaire ne devraient pas être accessibles. Techniquement, le package jdk.jfr.consumer du module jdk.jfr sera étendu avec des fonctionnalités d'accès asynchrone aux événements.
Comme vous le savez, l'API de fichiers Java NIO (New IO) existe depuis JDK 1.4, puis une nouvelle amélioration appelée Path a été introduite. Path est une interface qui remplace la classe java.io.File comme représentation d'un fichier ou d'un répertoire lorsque nous travaillons dans Java NIO. JEP 352 étend MappedByteBuffer pour charger une partie des données de fichier dans la mémoire non volatile (NVM). Cette mémoire informatique, dans laquelle les données ne seront pas perdues même en cas de mise hors tension (souvent appelée mémoire morte), est utilisée pour stocker les données de manière permanente. Cette proposition d'amélioration Java fournit un nouveau module et une nouvelle classe pour l'API JDK : le module jdk.nio.mapmode, qui propose de nouveaux modes (READ_ONLY_SYNC, WRITE_ONLY_SYNC) pour créer des tampons d'octets mappés (MappedByteBuffer) référençant NVM.
NullPointerExceptions sera désormais plus convivial pour les programmeurs. Dans le sens où la description de l’exception sera beaucoup plus informative qu’auparavant. En effet, la JVM a appris à analyser plus précisément les instructions du bytecode du programme et elle peut indiquer quelle variable conduit à une valeur nulle. Disons que nous avons le code :
a.getMessage().getUserInfo().getName()
Dans n'importe laquelle des dernières versions de Java, nous obtiendrons le journal d'erreurs habituel, qui ne répond pas à la question de savoir qui exactement est nul :
Exception in thread "main"java.lang.NullPointerException
at Main.main(Main.java:12)
Et voici ce que Java 14 vous offrira si vous décidez d’essayer cette fonctionnalité en avant-première :
Exception in thread "main"java.lang.NullPointerException:Cannot invoke "UserInfo().getName()" because the return value of "Message().getUserInfo()" is null
at Main.main(Main.java:12)
Cette chaîne est beaucoup plus compréhensible et vous permet de résoudre l'erreur beaucoup plus rapidement.
L'opérateur Switch mis à jour était disponible dans les versions précédentes de Java 12 et 13, mais uniquement en tant que fonctionnalité d'aperçu, c'est-à-dire qu'il n'était pas activé par défaut. Désormais, dans JDK 14, tout fonctionne immédiatement. Java 14 introduit une nouvelle forme simplifiée du bloc switch avec des étiquettes case L -> .... La nouvelle forme simplifie le code dans certains cas. Voici quelques exemples. Disons que nous avons une énumération qui décrit les jours de la semaine. On peut écrire du code classique (pré-Java 14) :
Vous pouvez également écrire des blocs multilignes et renvoyer une valeur avec le nouveau mot-clé rendement :
int result =switch(s){case"Working from Home"->1;case"Working from Office"->2;default->{System.out.println("Neither Home nor Office… Cafe? Car? Park?...");yield0;}};
Il y a quelques autres choses importantes à garder à l'esprit lors de l'utilisation des nouveaux commutateurs . En particulier, vous devez vous rappeler que les options doivent être exhaustives. Autrement dit, pour toutes les valeurs possibles, il doit y avoir une étiquette de commutateur correspondante. Puisque rendement est désormais un mot-clé, une classe appelée rendement est possible dans Java 14. En général, si vous souhaitez apprendre à utiliser les commutateurs mis à jour, accédez à JEP 361 et étudiez. Il y a beaucoup d'informations intéressantes là-bas.
Il est peu probable que beaucoup de nos lecteurs se souviennent du système d'exploitation Solaris . Ce système d'exploitation basé sur UNIX, créé par les parents de Java, Sun Microsystems, était principalement utilisé pour les serveurs sur l'architecture SPARC... Trop de mots inconnus par centimètre carré ? Ce n'est pas grave : la JEP 362 met fin à la prise en charge des plates-formes Solaris/SPARC, Solaris/x64 et Linux/SPARC. Autrement dit, leurs ports sont désormais obsolètes et, à l'avenir, ils seront très probablement supprimés d'OpenJDK. Cependant, les anciennes versions de Java (antérieures au JDK 14) concernant les ports Solaris/SPARC, Solaris/x64 et Linux/SPARC devraient fonctionner sans modification. Si vous êtes un passionné d'histoire et que vous êtes intéressé par les technologies d'un passé pas si lointain, allez sur Wikipédia et découvrez l' architecture SPARС .
Le garbage collector CMS (Concurrent Mark Sweep) est destiné à être supprimé car il y a deux ans, il a été marqué comme obsolète et n'a pas été maintenu. Cependant, les utilisateurs d'anciennes versions de Java utilisant le CMS GC peuvent expirer - le but de ce JEP n'est pas de supprimer le générateur des versions antérieures du JDK. De plus, la combinaison des algorithmes de récupération de place ParallelScavenge et SerialOld (exécutés avec les options « -XX:+UseParallelGC -XX:-UseParallelOldGC ») est obsolète.
Il existe un garbage collector intéressant appelé Z Garbage Collector (ZGC) . Il fonctionne en mode passif et essaie de minimiser les retards dus au garbage collection : le temps d'arrêt lors de l'utilisation de ZGC ne dépasse pas 10 ms. Il peut fonctionner avec des petits tas et des tas géants (ceux qui occupent plusieurs téraoctets). JEP 364 et JEP 365 sont pratiquement jumeaux. JEP 364 apporte Z Garbage Collector à MacOS. Une partie de la JEP décrit également la fonctionnalité de collecteur permettant de libérer la mémoire inutilisée de l'appareil, comme spécifié dans la JEP 351 , cela se produit depuis Java 13. L'implémentation de ZGC sur macOS comporte deux parties :
Prise en charge de la mémoire multi-mappage sur macOS
Prise en charge de ZGC pour la réservation continue de mémoire
JEP 365 prend en charge ZGC déjà sous Windows, ainsi qu'en mode expérimental. C'est le suivant :
Prise en charge de la mémoire multi-mappage
Prise en charge du mappage de mémoire basé sur le fichier d'échange dans un espace d'adressage réservé
Prise en charge du mappage et du démappage de parties arbitraires du tas
Prise en charge de la validation et de la désactivation de parties arbitraires du tas
Ce JEP déprécie la combinaison des algorithmes de récupération de place Parallel Scavenge et Serial Old. Cette combinaison devait être activée manuellement à l'aide des paramètres de ligne de commande -XX : + UseParallelGC -XX : -UseParallelOldGC. Les auteurs estiment que la combinaison est très spécifique, mais nécessite également un effort de maintenance important. Alors maintenant, l'option -XX: UseParallelOldGC est obsolète et un avertissement apparaîtra si elle est utilisée.
Pack200 est un format d'archive optimisé pour stocker les fichiers de classe Java compilés. Cet outil est marqué comme obsolète depuis Java 11. Désormais, les outils API pack200, unpack200 et Pack200 ont été officiellement annoncés pour leur suppression du package java.util.jar . Cette technologie a été introduite dans Java 5 comme moyen de gérer une bande passante très limitée (modems, c'est effrayant à dire et à retenir, 56 Ko) et un espace de stockage insuffisant sur les disques durs. Il y a quelque temps, Java 9 a introduit de nouveaux schémas de compression. Les développeurs sont encouragés à utiliser jlink .
Les blocs de texte sont apparus pour la première fois dans Java 13. Il s'agit de chaînes littérales multilignes qui évitent d'avoir recours à la plupart des séquences d'échappement, formatent automatiquement la chaîne et permettent également au développeur de formater la chaîne si nécessaire. Cette fonctionnalité utile est désormais disponible dans Java 14 (2e aperçu). L’objectif principal des blocs de texte est d’améliorer la gestion des littéraux multilignes déroutants. Cela simplifie grandement la lecture et l'écriture de requêtes SQL, de code HTML et XML et JSON. Exemple HTML sans blocs de texte :
String html ="<html>\n"+" <body>\n"+" <p>Hello, JavaRush Student</p>\n"+" </body>\n"+"</html>\n";
Comment représenter la même chose avec des blocs de texte :
Le délimiteur d'ouverture est une séquence de trois guillemets doubles ("" "), suivis de zéro ou plusieurs espaces, puis d'un délimiteur de ligne. Le contenu commence au premier caractère après le délimiteur de ligne du délimiteur d'ouverture. Le délimiteur de fermeture est une séquence de trois guillemets doubles " _ ) a été choisie pour que les caractères puissent être affichés sans s'échapper, et également distinguer visuellement un bloc de texte d'une chaîne littérale. Début 2019, la JEP 355 proposait des blocs de texte dans le prolongement de la JEP 326 (littéraux de chaîne brute), mais ils ont été retirés. Plus tard cette année-là, JDK 13 a introduit la fonctionnalité d'aperçu des blocs de texte, et Java 14 a désormais ajouté deux nouvelles séquences d'échappement. Il s'agit d'un terminateur de ligne, noté \, et le second est pour un espace simple, noté /s. Un exemple d'utilisation de nouvelles lignes sans blocs de texte :
String literal ="This is major Tom to Ground Control "+"I am stepping through the door... "+"Wait… What???";
Et maintenant avec la séquence d'échappement \<line-terminator> :
String text ="""
This is major TomtoGroundControl \
I am stepping through the door... \
Wait… What???\
""";
La séquence d'échappement \s est utilisée pour tenir compte des espaces de fin, qui sont ignorés par le compilateur par défaut. Il préserve tous les espaces qui le précèdent. Exemple:
De nombreuses bibliothèques et programmes Java populaires ont accès à la mémoire externe. Par exemple, Ignite, MapDB, Memcached et Netty ByteBuf API. Ce faisant, ils peuvent éviter le coût et l'imprévisibilité associés au garbage collection (en particulier lors de la gestion de caches volumineux), partager la mémoire entre plusieurs processus et sérialiser et désérialiser le contenu de la mémoire en mappant les fichiers en mémoire (par exemple, à l'aide de mmap). Cependant, l’API Java ne dispose toujours pas de solution adaptée pour accéder à la mémoire externe. JDK 14 inclut un aperçu de l'API Foreign-Memory Access , qui permet aux applications Java d'accéder de manière sécurisée et efficace aux régions de mémoire en dehors du tas JVM à l'aide des nouvelles abstractions MemorySegment, MemoryAddress et MemoryLayout.
conclusions
Alors qu'est-ce que tu en penses? Par rapport à Java 13, le nouveau Java 14 offre de nombreuses améliorations plus importantes dans divers domaines. Très probablement, le plus important pour les développeurs sera le commutateur mis à jour, les exceptions étendues NullPointerExceptions et les enregistrements. Ou pas ?.. N'oubliez pas d'essayer les nouvelles fonctionnalités de Java 14, c'est très utile même pour les débutants. Bonne chance dans tes études !
GO TO FULL VERSION