Oracle a annoncé la disponibilité générale de Java 15 lors du discours d'ouverture de sa conférence Developer Live, la version en ligne des événements annuels CodeOne et OpenWorld de la société.Le dernier kit de développement Java (JDK) offre de nouvelles fonctionnalités, certaines fonctionnalités en préversion désormais finalisées, des modules d'incubation (qui peuvent s'apparenter à des fonctionnalités expérimentales), la modernisation continue du code existant, une multitude de corrections de bogues et la dépréciation des fonctionnalités obsolètes.
Cette version intervient alors que Java fête ses 25 ans, a noté Georges Saab, vice-président du développement d'Oracle Java Platform Group, dans un communiqué.
« Alors que Java célèbre son 25e anniversaire, nous continuons à faire des investissements techniques qui font avancer l'innovation Java et contribuent à faire face à l'évolution rapide du paysage technologique », a déclaré Saab. « La disponibilité de Java 15 et l'innovation incrémentielle qui accompagne le passage à une cadence de publication de six mois donnent à la communauté Java les outils dont elle a besoin pour créer des applications modernes qui font avancer notre monde ».
Une correction de bogue sur quatre provient de développeurs tiers
Java 15 a été lancé avec la cadence de publication Java de six mois désormais bien établie, lancée par Oracle avec la version Java 10 en 2018. Il s'agit de la sixième version depuis l'annonce de la nouvelle cadence.
« Au lieu de rendre des dizaines de milliers de correctifs et une centaine de propositions d'amélioration JDK (JEP) disponibles dans une version majeure toutes les quelques années », a observé Sharat Chander, directeur de la gestion des produits Java SE chez Oracle, dans un billet de blog, « les améliorations sont livrées sous forme de versions de fonctionnalités plus petites selon un calendrier de six mois plus gérable et prévisible. Ces modifications peuvent aller d'une fonctionnalité importante à de petites améliorations, en passant par la maintenance de routine, les corrections de bogues et les améliorations de la documentation. Chaque modification est représentée dans un seul commit pour un seul problème dans le système de bogues JDK ».
« Sur les 2 136 problèmes JIRA marqués comme résolus dans Java 15, 1 702 ont été résolus par des personnes travaillant pour Oracle, tandis que 434 ont été apportés par des développeurs individuels et des développeurs travaillant pour d'autres organisations », a noté Chander.
« Oracle tient à remercier les développeurs travaillant pour des organisations comme ARM, Amazon, IBM, Intel, NTT Data, Red Hat, SAP et Tencent pour leurs contributions notables. Nous sommes également reconnaissants de voir les contributions de petites organisations telles que Ampere Computing, Bellsoft, Longsoon et des développeurs indépendants qui ont collectivement contribué à 3 % des correctifs de Java 15. Et, enfin et surtout, nous aimerions remercier les premières contributions de DataDog et Microsoft ».
La version Java 15 est le résultat d'un développement à l'échelle de l'industrie impliquant des révisions ouvertes, des versions hebdomadaires et une collaboration approfondie entre les ingénieurs Oracle et les membres de la communauté mondiale des développeurs Java via la communauté OpenJDK et le processus de communauté Java.
Nouveautés et améliorations dans Java 15
Java 15 s’accompagne de quatorze améliorations / modifications principales, dont un module d'incubation (qui peuvent s'apparenter à des fonctionnalités expérimentales), trois fonctionnalités en préversion, deux fonctionnalités obsolètes et deux suppressions.
Certaines améliorations sont introduites dans les modules Incubator, un moyen de mettre les API non finales et les outils non finaux entre les mains des développeurs, leur permettant d'offrir des commentaires qui peuvent à terme améliorer la qualité de la plateforme Java.
De même, certaines améliorations sont introduites en tant que fonctionnalités en préversion, qui sont des fonctionnalités de langage ou de machine virtuelle de la plateforme Java SE entièrement spécifiées, entièrement implémentées et pourtant non permanentes.
Enfin, certaines modifications visent à réduire la taille et la portée du JDK via la dépréciation. La dépréciation encourage les applications à s'éloigner de l'API, décourage les applications de former de nouvelles dépendances sur l'API et informe les développeurs des risques d'une dépendance continue à l'égard de l'API. Avec l'outil jdeprscan, introduit pour la première fois dans Java 9, les utilisateurs peuvent effectuer une analyse statique de leurs fichiers jar (ou une autre agrégation de fichiers de classe) pour identifier les utilisations d'éléments d'API obsolètes, leur permettant ainsi de se préparer à l'avance pour leur suppression future.
Nouvelles fonctionnalités
Algorithme de signature numérique Edwards-Curve
Cette fonctionnalité améliore la sécurité et les performances en implémentant des signatures cryptographiques à l'aide de l'algorithme de signature numérique Edwards-Curve (EdDSA) tel que décrit par la RFC 8032. EdDSA est un schéma de signature de courbe elliptique moderne qui présente plusieurs avantages par rapport aux schémas de signature existants dans le JDK. L'objectif principal de ce JEP est une implémentation de ce schéma tel que normalisé dans la RFC 8032. Ce nouveau schéma de signature ne remplace pas l'ECDSA.
L’ajout des Hidden Classes
Les Hidden Classes sont des classes qui ne peuvent pas être utilisées directement par le bytecode d'autres classes. Elles sont destinées à être utilisées par des frameworks qui génèrent des classes à l'exécution et les utilisent indirectement. Une Hidden Class peut être définie comme un membre d'une niche de contrôle d'accès et peut être déchargée indépendamment des autres classes.
L’ajout de cette fonctionnalité a été motivé, entre autres, par le fait que de nombreuses implémentations de langage construites sur la JVM reposent sur la génération dynamique de classes pour plus de flexibilité et d'efficacité, d’après la page de proposition. « Par exemple, dans le cas du langage Java, javac ne traduit pas une expression lambda dans un fichier de classe dédié au moment de la compilation mais, au contraire, émet un bytecode qui génère et instancie dynamiquement une classe pour produire un objet correspondant à l'expression lambda lorsque cela est nécessaire », lit-on sur la page.
Modernisation du code existant
Réimplémentation de l'ancienne API Datagram Socket
Cette fonctionnalité améliore la maintenabilité et la stabilité du JDK en remplaçant les implémentations sous-jacentes des API java.net.DatagramSocket et java.net.MulticastSocket par des implémentations plus simples et plus modernes. Les nouvelles implémentations seront faciles à adapter pour fonctionner avec des threads virtuels, actuellement explorées dans Project Loom.
Preview et fonctionnalités expérimentales qui sont maintenant finalisées
ZGC: un GC évolutif à faible latence
ZGC a été intégré dans JDK 11 par JEP 333, dans le but d'améliorer la productivité en réduisant les temps de pause GC, de gérer des tas allant de relativement petits (quelques centaines de mégaoctets) à très grands (plusieurs téraoctets), ainsi que de poser un base pour les futures fonctionnalités et optimisations du GC utilisant des pointeurs et des barrières de charge colorés. Avec JEP 377, ZGC passe de la catégorie de fonctionnalité expérimentale à fonctionnalité de production.
Blocs de texte pour une meilleure lisibilité de chaînes de caractères
Les blocs de texte sont destinés à simplifier la tâche d'écriture des programmes Java en facilitant l'expression de chaînes de caractères couvrant plusieurs lignes de code source, tout en évitant les séquences d'échappement dans les cas courants. Un bloc de texte est une chaîne littérale de plusieurs lignes qui évite la plupart des séquences d'échappement, formate automatiquement la chaîne de manière prévisible et offre au développeur le contrôle du format lorsqu'il le souhaite.
Les blocs de texte ont été proposés par le JEP 355 au début de 2019 et ont été ajoutés en prévisualisation au JDK 13 en juin 2019. Les réactions au JDK 13 ont suggéré qu’ils devaient demeurer en prévisualisation, avec des mises à jour, sur le JDK 14 en novembre 2019. Les commentaires sur le JDK 14 suggèrent que la fonction Text Blocks est maintenant prête à être rendue définitive et permanente, selon la page de proposition de l’OpenJDK.
L'un des objectifs de la proposition de blocs de texte est d'améliorer la lisibilité des chaînes dans les programmes Java qui indiquent du code écrit dans des langages autres que Java. Un autre objectif est de soutenir la migration à partir de chaînes de caractères littérales en stipulant que toute nouvelle construction peut exprimer le même ensemble de chaînes de caractères qu'une chaîne littérale, interpréter les mêmes séquences d'échappement et être manipulée de la même manière qu'une chaîne littérale. Les développeurs d'OpenJDK espèrent ajouter des séquences d'échappement pour gérer les espaces blancs explicites et le contrôle des nouvelles lignes.
Shenandoah
Shenandoah a été intégré dans JDK 12 par JEP 189. Il a été marqué comme expérimental afin de correspondre au statut d'autres nouveaux GC, notamment Epsilon GC et ZGC. JEP 379 fait passer récupérateur de mémoire Shenandoah d'une fonctionnalité expérimentale à une fonctionnalité de production mais ne propose pas de changer le GC par défaut, qui reste G1, et ne propose pas de changer le processus de développement de Shenandoah, qui continuera à prendre en charge les dernières JDK et JDK LTS / STS populaires.
Fonctionnalités d'incubation et en Preview
Classes Sealed (Preview 1)
Cette fonction en préversion améliore la productivité des développeurs en améliorant la programmation Java avec des classes et des interfaces Sealed, ce qui permet à l'auteur d'une classe ou d'une interface de contrôler quel code est responsable de son implémentation, fournit un moyen plus déclaratif que les modificateurs d'accès pour restreindre l'utilisation d'un superclasse et soutiennent les orientations futures de la correspondance de modèles en étayant l'analyse exhaustive des modèles.
Pattern Matching pour instanceof (Preview 2)
Cette fonction en Preview, qui a été introduite pour la première fois dans JEP 305 dans le cadre de JDK 14, améliore la productivité des développeurs en éliminant le besoin d'un code boilerplate et devrait permettre un code sécurisé de type plus concis.
Records (Preview 2)
Records améliore la productivité des développeurs en fournissant une syntaxe compacte pour déclarer des classes qui agissent comme des supports transparents pour les données immuables. Les Records ont été proposés par JEP 359 à la mi-2019 et livrés en tant que fonctionnalité en préversion dans JDK 14. Ce JEP propose de revoir la fonctionnalité dans JDK 15, à la fois pour incorporer des améliorations basées sur les commentaires et pour prendre en charge des formes supplémentaires de classes et d'interfaces locales dans le langage Java.
API Foreign-Memory Access (Incubator 2)
L'API Foreign-Memory Access a été proposée par JEP 370 et ciblée sur JDK 14 fin 2019 en tant qu'API d'incubation. Ce JEP propose d'incorporer des raffinements basés sur les commentaires et de réincuber l'API dans JDK 15. Cette fonctionnalité d'incubation définit une API pour permettre aux programmes Java d'accéder en toute sécurité et efficacement à la mémoire étrangère en dehors du tas Java.
Dépréciations et suppressions
Comme avec les versions de fonctionnalités précédentes, JDK 15 rend certaines fonctionnalités obsolètes et supprime les fonctionnalités précédemment obsolètes
Activation RMI obsolète, il sera supprimé dans une version future
JEP 385 déprécie le mécanisme d'activation RMI qui sera supprimé dans une version future. L'activation RMI est une partie obsolète de RMI qui est facultative depuis Java 8. Aucune autre partie de RMI ne sera obsolète.
Suppression du moteur JavaScript Nashorn
JEP 372 supprime le moteur de script et les API JavaScript Nashorn, ainsi que l'outil jjs. Le moteur, les API et l'outil ont été déconseillés pour suppression dans JDK 11 avec l'intention expresse de les supprimer dans une version ultérieure.
Suppression des ports Solaris et SPARC
JEP 381 supprime le code source et la prise en charge de build pour les ports Solaris / SPARC, Solaris / x64 et Linux / SPARC. Ces ports ont été marqués comme obsolète dans JDK 14 avec l'intention expresse de les supprimer dans une version ultérieure.
OpenJDK (JDK 15)Sources : note de version, annonce Oracle, Sharat Chander (Oracle)
Voir aussi :
Voici comment la startup Diffblue utilise l'IA pour automatiser les tests unitaires pour les applications Java à travers son outil dénommé "Diffblue Cover" C++ était le langage de programmation à la croissance la plus rapide en septembre selon TIOBE, Java a enregistré la plus forte baisse mais reste en seconde position La version open source du kit de développement Java (OpenJDK) débarque sur Windows 10 pour l'architecture ARM 64 bits au travers d'un projet de portage initié par Microsoft Red Hat publie Mandrel, une distribution Java qui compile les applications Java directement en code machine natif pour un démarrage plus rapide en utilisant moins de mémoire 
Envoyé par bouye
