JDK 14: les nouvelles fonctionnalités de Java 14

Le kit de développement Java (JDK) 14 a atteint GA, arrivant dans une version à disponibilité générale pour les déploiements de production. La mise à niveau vers Java standard inclut de nouvelles fonctionnalités telles que la diffusion d'événements JDK Flight Recorder, la correspondance de modèles et les expressions de commutation. 

JDK 14 est une version de fonctionnalités de Java, plutôt qu'une version de support à long terme (LTS), après la cadence de publication de six mois définie pour Java. Le JDK 14 recevra des mises à jour de sécurité en avril et juillet avant d'être remplacé par JDK 15, également une version non LTS, qui doit être publiée en septembre. La version actuelle de LTS est JDK 11. 

Les nouvelles fonctionnalités et améliorations du JDK 14 incluent:

  • JFR Event Streaming fournit une API pour la consommation continue des données JFR des applications en cours et hors processus. JFR est un outil permettant de collecter des données de profilage et de diagnostic sur une application Java et la JVM lors de leur exécution. La proposition de diffusion en continu d'événements enregistre le même ensemble d'événements que pour le cas sans diffusion en continu, avec une surcharge de moins d'un pour cent si possible. La diffusion d'événements doit coexister avec des enregistrements non diffusés, à la fois sur disque et en mémoire. Cette proposition est motivée par une situation dans laquelle la VM HotSpot émet plus de 500 points de données en utilisant JFR, la plupart d'entre eux disponibles uniquement en analysant les fichiers journaux. Actuellement, un utilisateur doit démarrer un enregistrement, l'arrêter, vider le contenu sur le disque, puis analyser le fichier d'enregistrement. Cela fonctionne bien pour le profilage d'application, mais pas à des fins de surveillance.Un exemple de surveillance de l'utilisation est un tableau de bord qui affiche les mises à jour dynamiques des données. La création d'un enregistrement entraîne une surcharge, telle que la copie des données du référentiel de disques vers un fichier d'enregistrement séparé. S'il y avait un moyen de lire les données enregistrées à partir du référentiel de disques sans créer un nouveau fichier d'enregistrement, une grande partie de la surcharge pourrait être évitée.
  • L'amélioration prévue à  NullPointerExceptionsconcerne l'amélioration de la convivialité des exceptions générées par la JVM en décrivant exactement quelle variable était nulle. Les auteurs de la proposition cherchent à fournir des informations utiles aux développeurs et au personnel d'assistance sur l'arrêt prématuré d'un programme et à améliorer la compréhension du programme en associant plus clairement une exception dynamique au code de programme statique. L'un des objectifs est de réduire la confusion et les préoccupations des développeurs NullPointerExceptions.
  • Les tampons d'octets mappés non volatils ajouteraient de nouveaux modes de mappage de fichiers spécifiques au JDK qui permettent à l'API FileChannel d'être utilisée pour créer des MappedByteBufferinstances faisant référence à la mémoire non volatile (NVM). NVM permet aux programmeurs de créer et de mettre à jour l'état du programme à travers les exécutions de programme sans encourir les coûts de copie ou de traduction importants que les opérations d'entrée et de sortie nécessitent habituellement. Ceci est particulièrement important pour les programmes transactionnels. Ainsi, l'objectif principal de cette proposition d'amélioration de JDK est de s'assurer que les clients peuvent accéder et mettre à jour NVM à partir d'un programme Java de manière cohérente et efficace. Un objectif secondaire est d'implémenter ce comportement de validation à l'aide d'une API JDK interne restreinte définie dans la classe Unsafe, afin qu'il puisse être réutilisé par des classes autres queMappedByteBufferqui peuvent avoir besoin de s'engager dans NVM. Un autre objectif est de permettre aux tampons mappés sur NVM d'être suivis par les API existantes pour la surveillance et la gestion. Les plates-formes OS / CPU cibles incluent Linux / x64 et Linux / AArch64.
  • Les expressions de commutation simplifient le codage en s'étendant  switchafin qu'il puisse être utilisé comme une instruction ou une expression. Les expressions de commutation devraient être une fonctionnalité permanente dans JDK 14, après avoir été prévisualisées à la fois dans JDK 12 et JDK 13. Les expressions de commutation préparent également l'utilisation de la correspondance de modèle dans switch. La correspondance de modèles permet aux développeurs d'extraire conditionnellement les composants des objets de manière plus concise et plus sûre. 
  • Allocation de mémoire compatible NUMA pour le garbage collector G1, destinée à améliorer les performances de G1 sur les grandes machines. 
  • Suppression du garbage collector Concurrent Mark Sweep (CMS), qui était auparavant obsolète et dont la suppression était prévue. Des successeurs de CMS sont apparus, notamment ZGC et Shenandoah. 
  • Portage de ZGC vers MacOS. Il a été pris en charge uniquement sur Linux jusqu'à présent.
  • Suppression des outils pack200 et unpack200 et de l'API Pack200 dans le java.util.jarpackage. Tous ces éléments étaient obsolètes dans Java SE 11 avec l'intention de les supprimer à l'avenir. Pack200 est un schéma de compression pour les fichiers JAR.
  • Records, qui fournirait une syntaxe compacte pour déclarer des classes qui sont des détenteurs transparents pour des données peu profondes immuables. Les enregistrements facilitent la création de classes qui sont essentiellement des supports de données sans avoir à écrire beaucoup de passe-partout. La proposition stipule qu'il devrait être facile et concis de déclarer des agrégats de données nominaux peu profonds et bien comportés.
  • Un outil de packaging, en phase de développement incubateur, pour le packaging d'applications Java autonomes. L'outil serait basé sur JavaFX javapackager. Un tel outil avait été inclus dans Java mais a été coupé de JDK 11 dans le cadre de la suppression de JavaFX.
  • Améliorez la langue avec la correspondance de modèle pour l' instanceof opérateur. Ce serait une fonctionnalité de prévisualisation dans JDK 14. La correspondance de modèles permet à la logique commune d'un programme, principalement l'extraction conditionnelle de composants à partir d'objets, d'être exprimée de manière plus concise et sûre. Le code peut être bref et sécurisé.
  • Un deuxième aperçu des blocs de texte, un littéral de chaîne multiligne qui évite le besoin de la plupart des séquences d'échappement et met automatiquement en forme la chaîne de manière prévisible. Les blocs de texte donneraient au développeur le contrôle du format lorsqu'il le souhaitait, simplifieraient l'écriture des programmes Java et amélioreraient la lisibilité des chaînes. Les blocs de texte ont été prévisualisés dans JDK 13; l'itération JDK 14 ajouterait des séquences d'échappement pour gérer les espaces blancs explicites et le contrôle de nouvelle ligne.
  • Abandon de la combinaison des algorithmes de récupération de place Parallel Scavenge et Serial Old. Les responsables de Java pensent que cette combinaison est très peu utilisée mais nécessite beaucoup de maintenance.
  • Portage du ZGC (Z Garbage Collector) vers Windows. Cette fonctionnalité a de nouveau été déplacée vers la liste officiellement ciblée, après avoir été rétablie dans la liste proposée pour le ciblage.
  • API d'accès à la mémoire étrangère, avec l'introduction d'une API pour les programmes Java pour accéder en toute sécurité et efficacement à la mémoire étrangère en dehors du tas Java. Cette API devrait servir d'alternative aux principales voies par lesquelles les programmes Java accèdent à la mémoire, y compris nio.ByteBufferet sun.misc.Unsafe. La nouvelle API devrait pouvoir fonctionner sur différents types de mémoire, y compris la mémoire native, persistante et le tas géré. Il ne devrait pas être possible pour l'API de compromettre la sécurité de la JVM. La désallocation de la mémoire doit être explicite dans le code source. L'API devrait contribuer au développement du support d'interopérabilité natif qui est l'objectif du projet Panama.
  • Abandon des ports Solaris / Sparc, Solaris / x64 et Linux / Sparc, avec l'intention de les supprimer dans une version ultérieure. La suppression de la prise en charge de ces ports permettra aux contributeurs OpenJDK d'accélérer le développement de nouvelles fonctionnalités. Bien que Solaris et Sparc aient été des technologies de base chez Sun Microsystems, le créateur original de Java, ils ont été remplacés ces dernières années dans l'espace technologique par le système d'exploitation Linux et les processeurs Intel.

Où télécharger le JDK 14

Vous pouvez télécharger le JDK 14 open source à partir de jdk.java.net pour Linux, Windows et macOS. Vous pouvez télécharger les téléchargements commerciaux Oracle Java SE 14 à partir d'Oracle.com.