La version stable du JDK 13 a été publiée il y a environ un mois et l’équipe de JDK a déjà commencé à travailler sur la version 14 du JDK. L’OpenJDK a publié ce mois un aperçu des fonctionnalités attendues dans la prochaine version du kit de développement prévu pour 2020. Le JDK 14 devrait prendre l’événement JFR en streaming (JFR Event Streaming) et prendre également en charge les tampons d'octets de mappage de fichiers compatibles NVM. La version stable du JDK 14 est prévue pour le mois de mars 2020, mais deux RC devraient être publiées les 6 et 20 février 2020.Le JDK (Java Development Kit) 14 est prévu pour être publié le 17 mars 2020, et un aperçu des fonctionnalités qu’il pourrait apporter est déjà rendu disponible par l’OpenJDK. Rappelons que l’OpenJDK a mis en place depuis Java 10 un nouveau calendrier de publication des versions du JDK. Les nouvelles versions seront publiées tous les six mois, ce qui signifie qu’il y a aura deux versions du JDK par an. Le JDK 14 devrait apporter la prise en charge définitive des expressions switch. Un aperçu de cette fonctionnalité est venu avec le JDK 12 et un autre avec le JDK 14.
Pour l’instant, l’OpenJDK a annoncé trois propositions prévues pour apparaître dans le JDK, notamment JFR Event Streaming, les tampons d'octets mappés non volatils, etc. Voyons en détail ce dont il s’agit.
JFR Event Streaming
Cette fonctionnalité fournit une API pour la consommation continue des données JFR des applications en cours et hors processus. C’est un outil de collecte de données de profilage et de diagnostic sur une application Java en cours d'exécution. La proposition de diffusion en continu des événements enregistre le même ensemble d'événements que pour le cas non-en transmission, avec un temps système inférieur à 1 % si possible. La diffusion en continu d'événements doit coexister avec les enregistrements non diffusés en continu, qu'ils soient sur disque ou en mémoire.
Cette proposition est motivée par le fait que la VM HotSpot émet plus de 500 points de données en utilisant JFR, la plupart d'entre eux n'étant disponibles qu'en analysant les fichiers journaux. Actuellement, un utilisateur doit lancer un enregistrement, l'arrêter, vider le contenu sur le disque, puis analyser le fichier d'enregistrement. L’on estime que cela fonctionne bien pour le profilage d'application, mais pas à des fins de surveillance. Un exemple d'utilisation de la surveillance est un tableau de bord qui affiche les mises à jour dynamiques des données.
En effet, la création d'un enregistrement entraîne une surcharge, telle que la copie des données du référentiel de disque dans un fichier d'enregistrement séparé. S'il existait un moyen de lire les données en cours d'enregistrement à partir du référentiel de disque sans créer un nouveau fichier d'enregistrement, une grande partie de la surcharge pourrait être évitée.
Les tampons d'octets mappés non volatils
Les tampons d'octets mappés non volatils ajouteraient de nouveaux modes de mappage de fichiers spécifiques au JDK qui permettent d'utiliser l'API FileChannel pour créer des instances MappedByteBuffer qui font référence à la mémoire non volatile (NVM). NVM permet aux programmeurs de construire 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 requièrent habituellement. Cela est important pour les programmes transactionnels.
Ainsi, l'objectif principal de cette proposition d'amélioration du JDK est de s'assurer que les clients peuvent accéder et mettre à jour le NVM 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 restreinte, interne au JDK, définie dans la classe Unsafe, afin qu'elle puisse être réutilisée par des classes autres que MappedByteBuffer qui peuvent avoir besoin de valider 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 switch
Deux aperçus de cette fonctionnalité ont déjà été publiés dans les versions 12 et 13 du JDK. Les expressions switch simplifient le codage en étendant le switch pour qu'il puisse être utilisé comme une instruction ou une expression. Les expressions switch sont censées être une fonctionnalité permanente du JDK 14, après avoir été prévisualisées à la fois dans le JDK 12 et le JDK 13. Les expressions switch préparent également à l'utilisation de la correspondance de motifs dans switch, ce qui permettra aux développeurs d'extraire conditionnellement les composants des objets de manière plus concise et plus sûre.
Amélioration de NullPointerExceptions
L'amélioration prévue de NullPointerExceptions concerne 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 de soutien sur la cessation prématurée d'un programme et à améliorer la compréhension du programme en associant plus clairement une exception dynamique au code statique du programme. Un des buts est de réduire la confusion et l'inquiétude des développeurs au sujet de NullPointerExceptions.
Source : JDK 14
Et vous ?
Qu'en pensez-vous ? Quelles fonctionnalités souhaiteriez-vous avoir dans le JDK 14 ?Voir aussi
La version définitive du JDK 13 est publiée avec la prise en charge d'Unicode 12.1 et de nombreuses améliorations Java : une version à accès anticipé du JDK 13 est publiée, Oracle veut unifier les deux méthodes de la classe GraphicsEnvironment JDK 13 : toutes les fonctionnalités de la prochaine version du langage Java ont été verrouillées et une RC est prévue pour le 8 août prochain 
