La forme du kit de développement Java JDK 16, dont la sortie n’aura pas lieu avant le mois de mars 2021, se précise. Plusieurs propositions de fonctionnalités ont déjà été validées, notamment le support des fonctionnalités du langage C++ 14 dans le code source C++ du JDK, l’ajout d’une API vectorielle ainsi qu’une capacité dite « Elastic Metaspace » qui permet de restituer plus rapidement la mémoire de métadonnées de classe inutilisée vers le système d'exploitation. Après la sortie du JDK 15, le 15 septembre dernier, le JDK 16 deviendra l'implémentation de référence de la version de Java standard. Si le cycle de publication à six mois de Java standard est respecté, on peut estimer que le JDK 16 sera prêt en mars prochain.

A la date du 18 septembre, cinq propositions ont été acceptées pour le JDK 16. La plus récente, la capacité « Elastic Metaspace », a été ajoutée à la mi-septembre.

Détails sur les prochaines fonctionnalités

Les capacités à venir du JDK 16 :

- Capacité Elastic Metaspace : celle-ci permet de restituer plus rapidement la mémoire inutilisée de la classe HotSpot VM (metaspace) au système d'exploitation. Elle réduit l'empreinte et simplifie le code du metaspace pour faire baisser les coûts de maintenance. Le metaspace posait problème en cas de forte utilisation de la mémoire off-heap. Le projet prévoit le remplacement de l'allocateur de mémoire existant par un système d'allocation basé sur le jumelage, avec un algorithme qui divise la mémoire en partitions pour répondre aux besoins de mémoire. Cette approche a été utilisée par exemple pour le noyau Linux et permettra d'allouer la mémoire en plus petites portions afin de réduire la surcharge des chargeurs de classe. La fragmentation sera par la même occasion réduite. Par ailleurs, l’allocation de mémoire du système d'exploitation aux espaces de gestion de mémoire se fera lentement à la demande, afin de réduire l'encombrement des chargeurs qui démarrent avec de fortes allocations mais ne les utilisent pas immédiatement ou risquent de ne pas les utiliser totalement. Afin d'exploiter pleinement l'élasticité offerte par cette forme d’allocation jumelée, la mémoire du metaspace sera organisée en granules de taille uniforme qui pourront être alloués et restitués indépendamment les uns des autres.

- Activation des fonctionnalités du langage C++ 14 : celle-ci doit permettre l'utilisation des fonctionnalités du langage C++ 14 dans le code source C++ du JDK et fournir des indications spécifiques sur les fonctionnalités pouvant être utilisées dans le code de la VM HotSpot. Jusqu’au JDK 15, les fonctionnalités de langage utilisées par le code C++ dans le JDK ont été limitées aux normes du langage C++98/03. A partir du JDK 11, le code source a été mis à jour pour supporter des versions plus récentes du code C++ standard. Il est notamment possible de construire avec des versions récentes de compilateurs supportant les fonctionnalités 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 de la VM HotSpot. Mais pour tirer profit des fonctionnalités du langage C++, certaines modifications sont nécessaires en fonction du compilateur de la plate-forme.

- Une API vectorielle, en phase d'incubation, dans laquelle le JDK serait équipé d'un module d'incubation, jdk.incubator.vector, pour exprimer des calculs vectoriels qui compilent de manière optimale les instructions matérielles vectorielles sur les architectures CPU supportées, afin d'obtenir des performances supérieures à celles des calculs scalaires équivalents. L'API vectorielle apporte un mécanisme pour écrire des algorithmes vectoriels complexes en Java, en utilisant le support préexistant dans la VM HotSpot pour la vectorisation, mais avec un modèle utilisateur qui rend la vectorisation plus prévisible et plus robuste. Les objectifs de cette proposition sont notamment de fournir une API claire et concise pour exprimer une série de calculs vectoriels, d'être indépendant de la plate-forme en prenant en charge plusieurs architectures de CPU et d'offrir une compilation et des performances d'exécution fiables sur les architectures x64 et AArch64. La dégradation progressive fait aussi partie des objectifs. Elle implique qu’un calcul vectoriel pourrait se dégrader progressivement et continuer à fonctionner s'il ne peut pas être entièrement exprimé en cours d'exécution sous la forme d'une séquence d'instructions vectorielles matérielles, soit parce qu'une architecture ne prend pas en charge certaines instructions, soit parce qu'une autre architecture CPU n'est pas prise en charge.

- Migration des référentiels de code source OpenJDK de Mercurial vers Git. Cette migration présente plusieurs avantages : elle réduit la taille des métadonnées du système de contrôle de version, elle donne accès à nombre d’outils plus important et elle offre de nouvelles options d'hébergement.

- Migration vers GitHub, liée à la migration de Mercurial vers Git : les référentiels de code source du JDK 16 seront disponibles sur le site de partage de code populaire.

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 à courte durée (Short Terme Release), c’est-à-dire qu’elle sera supportée pendant six mois. Le JDK 17, prévu pour septembre 2021, sera une version de support à long terme (LTS). Elle bénéficiera d'un support pendant plusieurs années. Le JDK 11, sorti en septembre 2018, est la version LTS actuelle du JDK.