1 pièce(s) jointe(s)
Oracle annonce la disponibilité de Java 16
Le JDK 16 est déjà en cours de développement, bien que les travaux sur le JDK 15 continuent,
et devrait arriver avec la prise en charge des fonctionnalités du C++ 14
Bien que les travaux sur le JDK 15 continuent, avec une disponibilité générale prévue pour le 15 septembre, le JDK 16, son successeur, est déjà en cours de développement. Le site Web de l’OpenJDK dédié à cet exercice recense désormais 3 JEP (JDK Enhancement Proposals). Prévu pour mars 2021, le JDK 16 devrait arriver avec la prise en charge des fonctionnalités du C++ 14 dans le code source C++ du JDK. La communauté de l’OpenJDK prévoit également de migrer les référentiels de code source OpenJDK de Mercurial vers Git (GitHub) pour diverses raisons.
Activation des fonctionnalités du langage C++ 14
Selon la description donnée par le JEP 347, ce changement vise l'utilisation des fonctionnalités du C++ 14 dans le code source C++ du JDK et à donner des indications spécifiques sur les fonctionnalités qui peuvent être utilisées dans le code de la VM HotSpot. Par le biais du JDK 15, les caractéristiques du langage utilisées par le code C++ dans le JDK ont été limitées aux normes du langage C++ 98/03. Avec le JDK 11, le code source a été mis à jour pour permettre la construction avec des versions plus récentes du standard C++.
Cela inclut la possibilité de construire avec des versions récentes de compilateurs qui prennent en charge les caractéristiques du langage C++ 11/14. La présente proposition ne propose aucun changement de style ou d'usage pour le code C++ utilisé en dehors du HotSpot. Les règles sont déjà différentes pour le code du HotSpot et pour le code non HotSpot. À titre d’exemple, les exceptions C++ sont utilisées dans certains codes non HotSpot. Par contre, elles sont interdites dans HotSpot par les options de compilation.
Cependant, les exigences de cohérence de la construction rendront les nouvelles fonctionnalités du langage disponibles pour une utilisation dans tout le code C++ du JDK. Ensuite, pour tirer profit des fonctionnalités du langage C++, certaines modifications doivent être apportées au fil du temps, les détails dépendant du compilateur de la plateforme. Les versions minimales acceptables des différents compilateurs de plateforme doivent également être spécifiées. Le standard de langage souhaité doit être spécifié explicitement.
Migration des dépôts de code source OpenJDK de Mercurial vers Git
Le développement du JDK 16 se fera en même temps que la migration des référentiels de code source de la communauté OpenJDK de Mercurial (hg) vers Git. Le JEP 357 donne plusieurs raisons à cela. L’une d’entre elles est que les premiers prototypes de dépôts convertis montrent une réduction significative de la taille des métadonnées de contrôle de version. Par exemple, le répertoire .git du dépôt jdk/jdk est d'environ 300 Mo avec Git et le répertoire .hg est d'environ 1,2 Go avec Mercurial, selon la version de Mercurial utilisée, ce qui présente plusieurs avantages.
Le JEP 357 indique que cette réduction des métadonnées préserve l'espace disque local et réduit les temps de clonage, car moins de bits doivent passer par le fil. Git comporte également des clones peu profonds qui ne clonent que des parties de l'historique, ce qui permet de réduire encore les métadonnées pour les utilisateurs qui n'ont pas besoin de l'historique complet. Ainsi, l’objectif de cette action est de migrer tous les projets OpenJDK à dépôt unique de Mercurial vers Git, conserver l'historique du contrôle des versions, y compris les balises, reformater les messages d'engagement selon les meilleures pratiques de Git, porter les outils jcheck, webrev et defpath vers Git et créer un outil de traduction entre les hachages Mercurial et Git.
La migration vers GitHub
La migration vers GitHub est liée à la migration de Mercurial vers Git, avec des dépôts de code source JDK 16 qui seront sur le populaire site de partage de code. Mais pourquoi GitHub ? Le JEP 369 indique que la motivation pour choisir GitHub est qu'il excelle dans les trois principales raisons de choisir un fournisseur externe. Les performances de GitHub sont aussi bonnes, voire supérieures à celles des autres fournisseurs, c'est le plus grand service d'hébergement de code source au monde (50 millions d'utilisateurs en mai 2020), et il possède l'une des API les plus complètes.
Ce choix est aussi motivé par l'API étendue de GitHub qui permet la prise en charge de nombreux outils, notamment des éditeurs de texte, des EDI, des outils de ligne de commande et des clients de bureau graphique. Les versions préliminaires du JDK 16 pour Linux, Windows et macOS sont disponibles à l'adresse jdk.java.net. Comme le JDK 15, le JDK 16 sera une version à court terme, supportée pendant six mois. Le JDK 17, prévu pour septembre 2021, sera une version de support à long terme (LTS) qui bénéficiera d'un support pendant plusieurs années. La version actuelle du LTS, le JDK 11, est sortie en septembre 2018.
Source : Site de l’OpenJDK
Et vous ?
:fleche: Qu'en pensez-vous ?
Voir aussi
:fleche: Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors et supprimera le moteur JavaScript Nashorn
:fleche: Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
:fleche: JDK 14 va apporter plus de fonctionnalités que les deux versions précédentes combinées. Petit tour d'horizon sur celles qui sont susceptibles d'intéresser le plus les développeurs
:fleche: Le JDK 9 va supporter la compilation anticipée (AOT) en commençant par les systèmes Linux 64-bit exécutant Java 64-bit
1 pièce(s) jointe(s)
Oracle annonce la disponibilité de Java 16
Oracle annonce la disponibilité de Java 16
Tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
Oracle annonce la disponibilité de Java 16 avec 17 nouveautés (JEP) visant à améliorer la productivité des développeurs. La dernière version du Java Development Kit (JDK) intègre la finalisation des enregistrements et du filtrage par motif (Pattern Matching) pour l'opérateur instanceof, ainsi que des améliorations du langage présentées en préversion dans Java 14. Les développeurs pourront également utiliser le nouvel outil de packaging pour livrer des applications Java autocontenues, mais aussi découvrir trois interfaces de programmation en incubation : l'API Vecteur, l'API d'édition de liens étrangers et l'API d'accès à la mémoire étrangère. Il y a en outre une fonctionnalité qui est disponible en préversion : les classes scellées.
Oracle publie tous les six mois des mises à jour de Java afin que les développeurs puissent s'appuyer sur un calendrier de sorties prévisible. Les innovations sortent à un rythme soutenu pour améliorer constamment la performance, la stabilité et la sécurité, et contribuer à la diffusion de Java dans toutes les entreprises de tous les secteurs d'activité, quelle que soit leur taille.
Ainsi, après un semestre de collaboration intense entre les ingénieurs Oracle et les membres de la communauté Java, le JDK 16 est disponible avec son lot de nouveautés : ont été intégrées 17 propositions d'améliorations (JEP) relatives au langage, aux outils, à la gestion de la mémoire, avec de nouvelles fonctionnalités en statut incubation ou préversion.
Améliorations du langage présentées dans JDK 14 et finalisées dans JDK 16
- JEP 394 : le filtrage par motif (Pattern Matching) pour l'opérateur instanceof.
- JEP 395 : les enregistrements (Records)[/B], qui peuvent être vus comme des tuples nominaux.
Un nouvel outil pour améliorer la productivité des développeurs
- JEP 392 : un outil de packaging, jpackage, pour packager des applications Java autocontenues.
Améliorations de la gestion de la mémoire pour augmenter encore les performances
- JEP 387 : métaespace élastique. Cela permet de restituer plus rapidement au système d'exploitation la mémoire classe-métadonnées HotSpot inutilisée (c'est-à-dire le métaespace, ou metaspace), diminuer l'empreinte du métaespace et simplifier le code du métaespace pour réduire les coûts de maintenance.
- JEP 376 : traitement simultané de la pile de threads de ZGC. Il s'agissait ici de déplacer le traitement de la pile de threads de ZGC des points de sécurité (safepoints) vers une phase concurrente.
Amélioration du réseau pour renforcer la souplesse et la productivité des développeurs
- JEP 380 : les canaux des sockets de domaine UNIX. L'amélioration consiste à ajouter le support de toutes les fonctionnalités des sockets de domaine Unix (communes à Windows et aux plus grandes plateformes Unix) aux API de canaux de socket et de canaux de socket serveur dans le package java.nio.channels. Les sockets de domaine Unix sont utilisées pour les communications interprocessus (IPC) sur le même hôte. Elles sont en de nombreux points comparables aux sockets TCP/IP, sauf qu'elles sont adressées par des noms de chemin du système de fichiers plutôt que par des adresses et des numéros de port Internet Protocol (IP).
Traitement du code incompatible avec les évolutions futures
- JEP 396 : encapsulage fort des internes du JDK par défaut. Dans le JDK 9, Oracle avait encapsulé fortement les nouveaux éléments de l'API interne, afin d'en limiter l'accès. Cependant, pour faciliter la migration, JDK 9 avait délibérément choisi de ne pas encapsuler fortement à l'exécution le contenu des packages qui existaient dans JDK 8. JDK 16 restreint cette contrainte en encapsulant par défaut la plupart des éléments internes du JDK, sauf pour des API internes critiques telles que sun.misc.Unsafe. Les utilisateurs finaux peuvent toujours choisir l'encapsulation forte plus légère qui était le comportement par défaut depuis JDK 9. Cette solution encourage les développeurs à migrer de l'utilisation d'éléments internes à l'utilisation des API standards, afin qu'eux-mêmes et leurs utilisateurs puissent passer sans problème aux futures versions de Java.
- JEP 390 : avertissements pour les classes basées sur des valeurs. La proposition ici était de désigner les classes enveloppantes primitives comme étant basées sur des valeurs et déprécier leurs constructeurs pour encourager leur suppression, en générant de nouveaux avertissements de dépréciation. Cette version génère des avertissements de tentatives inappropriées de synchronisation sur des instances de toute classe basée sur des valeurs dans la plateforme Java.
Fonctionnalités en statut d'incubation ou en préversion
- JEP 338 : API Vecteur. Cette fonctionnalité fournit une itération initiale d'un module en incubation, jdk.incubator.vector, pour exprimer des calculs de vecteurs se compilant de façon fiable à l'exécution vers des instructions matérielles optimales de vecteurs sur les architectures CPU supportées.
- JEP 389 : API d'édition de liens étrangers (Foreign Linker API). Cette fonctionnalité en statut d'incubation introduit une API offrant un accès au code natif pur Java typé statiquement.
- JEP 393 : API d'accès à la mémoire étrangère (Foreign-Memory Access API). Cette fonctionnalité également en statut d'incubation introduit une API permettant aux programmes Java d'accéder de façon sure et efficace à la mémoire étrangère à l'extérieur du heap Java.
- JEP 397 : Classes scellées (préversion). Cette nouveauté enrichit le langage de programmation Java avec des classes et interfaces scellées. Les classes et interfaces scellées restreignent les autres classes ou interfaces qui pourront les étendre ou les implémenter.
Améliorations pour les contributeurs d'OpenJDK
- JEP 347 : activation des fonctionnalités du langage C++14 (dans le code source du JDK). Cette amélioration vise à permettre l'utilisation des fonctionnalités du langage C++14 dans le code source C++ du JDK, et formuler des recommandations précises sur les fonctionnalités qui peuvent être utilisées dans le code HotSpot.
- JEP 357 : migration de Mercurial vers Git. Il s'agissait ici de migrer les référentiels de codes sources de la communauté OpenJDK depuis Mercurial (hg) vers Git.
- JEP 369 : migration vers GitHub (hébergement des référentiels Git de la communauté OpenJDK sur GitHub).
De nouveaux portages pour le support de Java sur encore plus de plateformes
- JEP 386 : portage du JDK sur Alpine Linux et sur d'autres distributions Linux utilisant musl comme bibliothèque C primaire, sur les deux architectures x64 et AArch64.
- JEP 388 : portage du JDK sur Windows/Aarch64
Selon Georges Saab, Vice-Président d'Oracle en charge du développement de la plateforme Java, cette dernière version démontre toute la puissance de ce rythme semestriel. « Le filtrage par motif et les enregistrements étaient apparus pour la première fois il y a un an avec le JDK 14, ils ont, depuis, intégré plusieurs cycles de commentaires de la communauté basés sur leur utilisation dans des applications opérationnelles. Ce processus a permis aux développeurs Java d'expérimenter ces fonctionnalités avant leur finalisation, mais il a aussi permis de tenir compte de ces retours essentiels pour aboutir à deux JEP solides comme le roc, qui répondent vraiment aux besoins de la communauté », dit-il. Java 16 est disponible en téléchargement pour les différentes plateformes prises en charge.
Source : Oracle, Nouveautés du JDK 16
Et vous ?
:fleche: Que pensez-vous de ces nouvelles fonctionnalités et améliorations ?
:fleche: Lesquelles appréciez-vous le plus ? Pourquoi ?
:fleche: Quelles fonctionnalités disponibles dans les autres langages aimeriez-vous voir dans Java ?
Voir aussi :
:fleche: Marquée obsolète depuis 2016, l'API Applet sera bientôt définitivement supprimée de Java, y a-t-il des raisons de regretter les applets Java ?
:fleche: Alors que Java fête ses 25 ans, Oracle annonce l'arrivée de JDK 15. Cette version modernise le code existant et s'accompagne de la suppression du moteur JavaScript Nashorn
:fleche: Le JDK 16 est déjà en cours de développement, bien que les travaux sur le JDK 15 continuent, et devrait arriver avec la prise en charge des fonctionnalités du C++ 14
