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 ?

Qu'en pensez-vous ?

Voir aussi

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

Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres

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

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