Classes cachées, classes scellées, blocs de texte , enregistrements et EdDSA: JDK 15 a beaucoup de valeur.
Comme le dit l'une de mes expressions préférées, Java 15 contient beaucoup de bienfaits du chocolat. La nouvelle version (publiée le 15 septembre 2020) comprend 14 changements importants (JEP) visant à améliorer le JDK. Cet article fournit un aperçu rapide des nouveaux produits en fonction des informations contenues dans le JEP.
Les 14 JEP peuvent être divisés en cinq groupes. Pour une étude plus détaillée, consultez la documentation de chacun d'eux.
Nouvelle fonctionnalité à couper le souffle:
- JEP 339: algorithme de signature numérique Edwards Curve (EdDSA)
- JEP 371: Classes cachées
Ajouts à la fonctionnalité standard Java SE existante:
- JEP 378: blocs de texte
- JEP 377: ramasse-miettes ZGC
- JEP 379: Shenandoah - Collecteur de déchets à faible pause
Améliorations des fonctionnalités héritées de Java SE:
- JEP 373: Refonte de l'API DatagramSocket obsolète
Nous attendons avec impatience de nouveaux produits:
- JEP 360: classes scellées (aperçu)
- JEP 375: Pattern Matching for instanceof (Second Preview)
- JEP 384: Entrées (deuxième projet)
- JEP 383: API d'accès à la mémoire externe (deuxième fonction d'incubateur)
Suppression et résiliation du support:
- JEP 372: Nashorn JavaScript Engine
- JEP 374:
- JEP 381: Solaris SPARC
- JEP 385: RMI
,
Algorithme de signature numérique Edwards Curve ( JEP 339 ). Je serai le premier à admettre que l'algorithme de signature numérique Edwards-Curve (EdDSA) dépasse un peu ma connaissance du cryptage. D'accord, je n'en sais rien du tout. Cependant, ce JEP est conçu comme une implémentation indépendante de la plate-forme d'EdDSA avec de meilleures performances que l'implémentation C existante, ECDSA.
Selon la documentation JDK, EdDSA est un schéma de signature de courbe elliptique moderne qui présente plusieurs avantages par rapport à ceux existants dans le JDK.
Objectifs de mise en œuvre:
- L'objectif principal de ce JEP est d'implémenter le schéma de signature tel que normalisé dans la RFC 8032 . Cependant, le nouveau système ne remplace pas l'ECDSA.
- - EdDSA , ECDSA . , EdDSA, Curve25519 ~126 , , ECDSA, secp256r1 ~128 .
- , . .
Maintenant tu en sais plus que moi. Restez à l'écoute pour un article de Java Magazine expliquant EdDSA bientôt.
Les classes cachées ( JEP 371 ) sont des classes qui ne peuvent pas être appelées directement par le bytecode d'autres classes. Ils sont destinés à être utilisés par des frameworks qui créent dynamiquement des classes au moment de l'exécution et les utilisent indirectement via un mécanisme de réflexion. Les classes générées dynamiquement peuvent n'être requises que pendant une durée limitée, donc les conserver pendant la durée de vie d'une classe générée statiquement peut augmenter inutilement l'encombrement mémoire.
Les classes générées dynamiquement sont également indétectables. Trouver de telles classes par leur nom serait préjudiciable, car cela compromet leur objectif, qui est qu'elles ne sont qu'un détail d'implémentation d'une classe générée statiquement.
La publication des classes cachées jette les bases pour que les développeurs arrêtent d' utiliser l'API non standard sun.misc.Unsafe :: defineAnonymousClass . Oracle a l'intention de supprimer et de supprimer cette classe à l'avenir.
Ajouts aux normes Java SE existantes
Les blocs de texte ( JEP 378 ) issus du projet Amber ont finalement été publiés après deux versions préliminaires dans les JDK 13 et 14. Le but de leur création était le désir des développeurs de réduire la difficulté de déclarer et d'utiliser des littéraux de chaîne multi-lignes en Java.
Les blocs de texte mettent automatiquement en forme les chaînes de manière prévisible, mais si cela ne suffit pas, le développeur peut prendre en charge la mise en forme. La deuxième version de la fonctionnalité préliminaire introduit deux nouvelles séquences d'échappement pour la gestion des nouvelles lignes et des espaces. Par exemple, \ <line-terminator> supprime explicitement l'insertion d'un caractère de nouvelle ligne.
Auparavant, pour imprimer une longue ligne de texte, vous deviez écrire comme ceci:
L'utilisation de \ facilite la lecture du code:
La séquence d'échappement \ s peut empêcher la suppression des espaces de fin. Ainsi, le texte suivant représente trois lignes, dont chacune contient exactement cinq caractères (dans la ligne médiane, correspondant au vert, \ s n'est pas utilisé, car il contient déjà cinq caractères).
Le garbage collector ZGC ( JEP 377 ) a été introduit dans JDK 11 en tant que fonctionnalité expérimentale. Maintenant, il a reçu un statut officiel. ZGC est un garbage collector parallèle, compatible NUMA et évolutif avec une faible latence de garbage collection (moins de 10 millisecondes même sur des tas de plusieurs téraoctets). Le temps de pause moyen, tel que testé par Oracle, est inférieur à 1 milliseconde et le maximum est inférieur à 2 millisecondes. La figure 1 compare le garbage collector parallèle Java, G1 et ZGC, avec le temps de pause ZGC augmenté d'un facteur 10.
Figure 1. Comparaison des temps de pause du garbage collector
Cependant, pour de nombreuses charges de travail, G1 (qui est toujours la valeur par défaut) peut être légèrement plus rapide que ZGC. Aussi, pour les très petits tas, tels que ceux qui ne font que quelques centaines de mégaoctets, le G1 peut également être plus rapide. Ainsi, il vous est conseillé d'exécuter vos propres tests avec vos charges pour voir quel garbage collector utiliser.
Important: comme le ZGC n'est plus expérimental (inclus dans la version Oracle OpenJDK et dans le JDK Oracle), vous n'avez plus besoin d'utiliser -XX: + UnlockExperimentalVMOptions pour l'activer.
Shenandoah ( JEP 379) Est une autre variante du garbage collector disponible dans certaines versions d'OpenJDK. Il est expérimental depuis le JDK 12. Maintenant, comme avec ZGC, XX: + UnlockExperimentalVMOptions n'est pas nécessaire.
Modernisation de l'ancienne fonctionnalité Java SE
Refonte de l'API DatagramSocket obsolète ( JEP 373 ). Considérez ceci essentiellement comme une refactorisation de certains codes jurassiques, car ce JEP remplace les anciennes implémentations difficiles à maintenir des API java.net.DatagramSocket et java.net.MulticastSocket avec des implémentations plus simples et modernes, faciles à entretenir et à déboguer, et qui travailler avec les flux virtuels Project Loom.
Comme il y a beaucoup de code qui utilise l'ancienne API (depuis JDK 1.0), l'implémentation obsolète ne sera pas supprimée. En fait, une nouvelle propriété système spécifique au JDK, jdk.net.usePlainDatagramSocketImpl, configure le JDK pour utiliser une implémentation obsolète si la refactorisation de l'API pose des problèmes avec les tests de régression ou dans certains cas.
Nous attendons avec impatience de nouveaux produits
Classes scellées ( JEP 360 ). La première version provisoire créée dans Project Amber. Les classes et interfaces scellées limitent leur extension ou leur implémentation à d'autres classes. Pourquoi c'est important? Un développeur peut souhaiter gérer le code responsable de l'implémentation d'une classe ou d'une interface particulière. Les classes scellées fournissent un moyen plus déclaratif que les modificateurs d'accès pour restreindre l'utilisation de la superclasse. Par exemple:
Le but de sceller une classe est de faire savoir au code client quelles sous-classes sont autorisées. Après tout, il peut y avoir des cas d'utilisation où la définition originale d'une classe (ou d'une interface) est censée être complètement exhaustive, et lorsque le développeur ne permet pas son extension hors de contrôle - seules les classes explicitement spécifiées le peuvent.
Il existe certaines restrictions pour les classes scellées:
- La classe scellée et ses sous-classes autorisées doivent être dans le même module. S'ils sont déclarés dans un module sans nom, ils doivent être placés dans le même package
- Chaque sous-classe autorisée doit étendre directement la classe scellée
- , , , — final, sealed nonsealed ( )
Correspondance de modèle par exemple de ( JEP 375 ). Le deuxième aperçu est un autre développement de Project Amber. La première version préliminaire de la fonctionnalité était en Java 14 et il n'y a aucun changement par rapport à cela.
L'objectif est d'améliorer Java grâce à la correspondance de modèles pour l'opérateur instanceof. Cela vous permet d'exprimer de manière plus concise et sûre la logique générale du programme, à savoir l'extraction conditionnelle de composants à partir d'objets. Permettez-moi de vous référer à l'excellent article de Mal Gupta " Pattern Matching for instanceof in Java 14 " à titre d'exemple.
Entrées ( JEP 384), deuxième brouillon. Les enregistrements sont des classes qui agissent comme des supports transparents de données immuables. Le nouveau JEP comprend des clarifications basées sur les commentaires de la communauté et prend en charge plusieurs nouvelles formes supplémentaires de classes et d'interfaces locales. Les entrées proviennent également de Project Amber.
Les enregistrements sont une construction orientée objet qui exprime une simple agrégation de valeurs. Ainsi, ils aident les programmeurs à se concentrer sur la modélisation de données immuables plutôt que sur un comportement extensible. Les enregistrements implémentent automatiquement des méthodes basées sur les données telles que les égaux et les accesseurs. Les entrées préservent également les principes Java de longue date tels que le typage nominal et la compatibilité de migration. En d'autres termes, ils facilitent le codage et la lecture de classes contenant des données immuables.
L'accès à la mémoire externe ( JEP 383 ) est la deuxième version d'incubateur de l'API qui permet aux programmes Java d'accéder en toute sécurité et efficacement à la mémoire externe en dehors du tas Java. L'objectif est de commencer à remplacer java.nio.ByteBuffer et sun.misc.Unsafe. Il fait partie du projet Panama qui améliore la communication entre Java et d'autres API.
Le JEP décrit avec justesse la nécessité de cette innovation comme suit:
Lorsqu'il s'agit d'accéder à la mémoire externe, les développeurs sont confrontés à un dilemme - s'ils choisissent un chemin sûr, mais limité (et peut-être moins efficace), comme l'API ByteBuffer, ou devraient-ils abandonner les garanties de sécurité et adopter une API Unsafe dangereuse et non prise en charge?
Ce JEP introduit une API sécurisée, maintenable et efficace pour accéder à la mémoire externe. En apportant une solution ciblée au problème de l'accès à la mémoire externe, les développeurs seront libérés des limites et des dangers des API existantes. Ils obtiendront également de meilleures performances car la nouvelle API est conçue à partir de zéro avec les optimisations JIT à l'esprit.
Suppression et fin du support
Aucune de ces décisions ne devrait être controversée.
Suppression du moteur JavaScript Nashorn ( JEP 372 ). Ce moteur, son API et son outil jjs étaient obsolètes dans Java 11. Il est temps de dire au revoir.
La désactivation et l' élimination du verrouillage réservé ( JEP 374 ) supprime l'ancienne technique d'optimisation utilisée par HotSpot JVM pour réduire la surcharge associée au verrouillage non contrôlé. Ce verrouillage a toujours entraîné des améliorations de performances significatives par rapport aux méthodes de verrouillage conventionnelles, mais les gains de performances observés dans le passé sont beaucoup moins évidents aujourd'hui. Le coût de l'exécution des instructions atomiques sur les processeurs modernes a baissé.
Le verrouillage redondant a donné lieu à beaucoup de code complexe, et cette complexité empêche l'équipe de développement Java d'apporter des modifications importantes au moteur de synchronisation. En désactivant le verrou et en laissant au programmeur le soin de le réactiver, l'équipe de développement Java espère déterminer s'il serait judicieux de le supprimer entièrement dans une prochaine version.
Suppression des ports Solaris et SPARC ( JEP 381 ). Dans ce cas, tout le code source spécifique au système d'exploitation Solaris et à l'architecture SPARC est supprimé. Il n'y a plus rien à dire.
Excluez l'activation RMI pour une désinstallation ultérieure ( JEP 385). Simplifie Java en supprimant la partie obsolète de l'appel de méthodes distantes qui était facultative dans Java 8.
L'utilisation de l'activation RMI est réduite et réduite. L'équipe Java ne voit aucune preuve que de nouvelles applications ont été écrites en l'utilisant, et il est prouvé que très peu d'applications existantes utilisent l'activation RMI. La recherche dans diverses bases de code open source n'a trouvé presque aucune mention des API associées. Il n'y a pas eu de rapports d'erreurs d'activation RMI générées en externe depuis plusieurs années.
La prise en charge de l'activation RMI dans le cadre de la plate-forme Java a un coût de maintenance permanent. Cela ajoute de la complexité à RMI. Vous pouvez supprimer l'activation RMI sans affecter le reste de RMI. Le supprimer ne réduit pas la valeur du développeur Java, mais réduit les coûts de maintenance à long terme du JDK.
Conclusion
Java 15 poursuit son cycle de publication de six mois et est une version de taille moyenne utile à la plupart des développeurs.