Caractéristique linguistique : Classes scellées (JEP 409)

Les classes scellées pourraient être la fonctionnalité finalisée la plus attendue du JDK 17, et elles ont été prévisualisées dans le JDK 16. En bref, les classes scellées limitent les autres classes (ou interfaces) qui peuvent les étendre. Comme JEP 409 décrit, une classe ou une interface scellée ne peut être étendue ou implémentée que par les classes et interfaces autorisées à le faire. Une classe est scellée en appliquant le scellé modificateur à sa déclaration. Puis, après tout s'étend et met en oeuvre clauses, les permis La clause spécifie les classes qui sont autorisées à étendre la classe scellée. Si ces classes ne sont pas expressément autorisées à apporter des modifications, elles ne peuvent pas apporter de modifications.

Pourquoi devriez-vous vous en soucier ? Selon Aurelio Garcia-Ribeyro, directeur de la gestion des produits pour Java SE, « les classes scellées me permettent de créer un ensemble d'options dont je sais qu'elles sont finies, et cela simplifie le code car je peux alors traiter les classes comme si elles étaient des énumérations ».

Le fait d'avoir des classes scellées, dit-il, élimine la crainte qu'un autre code puisse remplacer votre code ou modifier son comportement d'une manière que vous ne pouvez pas anticiper. "Cela crée une garantie que personne ne peut améliorer une bibliothèque d'une manière qui cassera mon code à l'avenir."

Mise à niveau de la bibliothèque principale : filtres de désérialisation spécifiques au contexte (JEP 415)

Les filtres de désérialisation spécifiques au contexte s'appuient sur une fonctionnalité introduite dans Java 9 (voir JEP 290 : Filtrer les données de sérialisation entrantes). Cet ancien JEP offrait à la fois des filtres de désérialisation par flux modifiables et un filtre statique à l'échelle de la JVM. Les filtres par flux, malheureusement, n'ont pas bien évolué et il est difficile de mettre à jour les filtres après l'envoi du code. Les filtres de JEP 290 ne peuvent pas non plus imposer de filtrage sur les opérations de désérialisation effectuées par des bibliothèques tierces dans une application. Le filtre à l'échelle de la JVM était limité dans la mesure où il n'était spécifié qu'une seule fois, au démarrage, et était parfois trop inclusif ou trop restrictif.

La nouvelle fonctionnalité dans la JEP 415 est présenté comme une fabrique de filtres à l'échelle de la JVM. Les filtres sont dynamiques et spécifiques au contexte. Pour des raisons de compatibilité descendante, si aucune fabrique de filtres n'est définie, la fabrique intégrée renvoie un filtre statique à l'échelle de la JVM s'il en a été configuré un.

Le problème, dit Garcia-Ribeyro, est que chaque fois qu'un développeur créait un pipeline, le développeur devait définir ce qu'était le filtre, y compris une liste d'autorisation et une liste de refus. Cependant, selon Garcia-Ribeyro, "Si j'utilise une bibliothèque tierce, ils utilisent leurs propres flux. Je pouvais définir un filtre à l'échelle de la JVM, mais je devais savoir, à l'avance, tout ce que la bibliothèque voulait faire. Cela a demandé beaucoup de travail. »

En revanche, JEP 415 fournit une usine de filtres. "Avec une usine de filtres, les filtres de désérialisation sont désormais extrêmement plus faciles à utiliser", dit-il, "au point que c'est la seule fonctionnalité que nous retravaillons et modernisons déjà, jusqu'au JDK 11 et JDK 8".

Aucun délai n'est fixé pour le retour de la JEP 415 à l'ancienne version de Java, mais Garcia-Ribeyro insiste : "Nous y travaillons avec acharnement."

Mise à jour de la bibliothèque principale : nouveau pipeline de rendu macOS (JEP 382)

Utilisez-vous un Mac ? Oui, je ne sais pas ce que je ferais sans mon MacBook Pro quadricœur i7. Le nouveau pipeline de rendu macOS décrit par JEP 382 est assez simple : cela déplace les graphiques 2D de la JVM de l'utilisation de l'API Apple OpenGL obsolète vers la plus récente API Apple Métal. Bien sûr, si vous utilisez Java pour les charges de travail back-end, vous ne vous en soucierez probablement pas.

Apple a commencé à supprimer OpenGL dans macOS Mojave 10.14, informant : « Les API des frameworks OpenGL et OpenCL sont obsolètes et restent présentes à des fins de compatibilité. Passez à Metal si votre application utilise OpenGL ou OpenCL. »

Cette modification s'applique aux Mac à processeur Intel et ARM. Il s'agit d'un changement caché. Comme le dit la documentation JEP 382, « Les modifications se limitent au code spécifique à macOS et même là, seule une quantité minimale de code partagé entre Metal et OpenGL est mise à jour. Nous n'avons introduit aucune nouvelle API Java, ni modifié aucune API existante. »

La documentation JEP 382 note en outre : « Apple affirme que le framework Metal, leur remplaçant d'OpenGL, a des performances supérieures. Pour l'API Java 2D, c'est généralement le cas à quelques exceptions près.

Pour l'instant, la JVM Java 17 utilisera par défaut OpenGL ; il n'utilisera Metal que si OpenGL n'est pas présent ou si l'utilisateur lance un commutateur de ligne de commande. Garcia-Ribeyro demande cependant aux utilisateurs de Mac d'essayer le nouveau code. "Nous voulons que vous activiez ce nouveau pipeline de rendu. Il devrait être plus rapide ou au moins identique aux performances graphiques existantes sur Mac.

Aperçu : Pattern matching pour switch (JEP 406)

J'en ai probablement entendu parler correspondance de modèle pour interrupteur (PEC 406) que toute autre fonctionnalité du JDK 17 - et Garcia-Ribeyro en est également ravi. "Cette fonctionnalité rend Java meilleur pour tout le monde", dit-il, "et quelques versions plus tard, elle fera partie de la norme Java."

Ce PEC s'appuie sur les travaux de correspondance de modèle pour exemple de (PEJ 394), qui a été finalisé pour JDK 16. La nouvelle fonctionnalité offre deux grands avantages.

• Cela fait interrupteur déclarations beaucoup plus programmables et flexibles en permettant aux modèles d'apparaître dans Cas Étiquettes. Pour citer la documentation du JEP, « Vous ne pouvez interrupteur sur les valeurs de quelques types - types numériques, types enum et Corde - et vous ne pouvez tester que l'égalité exacte par rapport aux constantes. Nous aimerions peut-être utiliser des modèles pour tester la même variable par rapport à un certain nombre de possibilités, en prenant une action spécifique sur chacune, mais puisque les interrupteur ne supporte pas cela, on se retrouve avec une chaîne de sinon essais. »
• Il fournit un mécanisme plus gracieux (et convivial pour les développeurs) pour gérer les conditions nulles. Encore une fois, pour citer : « Traditionnellement, interrupteur déclarations et expressions lancer NullPointerException si l'expression du sélecteur est évaluée à null, le test de null doit donc être effectué en dehors du commutateur… C'était raisonnable lorsque interrupteur pris en charge que quelques types de référence. Toutefois, si interrupteur permet une expression de sélecteur de n'importe quel type, et les étiquettes de cas peuvent avoir des modèles de type, alors le test nul autonome ressemble à une distinction arbitraire, et invite un passe-partout inutile et une possibilité d'erreur.

Je m'attends à ce que la plupart des développeurs découvrent que lorsqu'ils essaient de faire correspondre des modèles pour interrupteur, ils diront : "Où étais-tu toute ma vie ?"