JDK 10 : la première release candidate est maintenant disponible

La sortie de la version stable est prévue pour le 20 mars

18/12/2017 : Conformément au calendrier de sortie du JDK 10, Mark Reinhold d'Oracle a annoncé le début de la phase Rampdown 1. Cette étape marque le gel de l'ensemble des fonctionnalités du JDK et le début de la correction des bogues. Dans une proposition, l'architecte en chef du JDK chez Oracle a donc défini ses objectifs pour cette nouvelle phase. Il s'agit notamment de corriger tous les bogues de priorité P1-P3 qui sont nouveaux dans le JDK 10 et des bogues P1-P3 supplémentaires ciblés pour le JDK 10 si le temps le permet. Il s'agira aussi de reporter tous les bogues P1-P2 qui sont nouveaux dans JDK 10, mais qui, pour une bonne raison, ne seront pas corrigés dans le JDK 10.

À ce stade, il est donc très peu probable d'introduire de nouveaux changements, excepté des améliorations tardives et à faible risque qui ajoutent de petits éléments de fonctionnalités manquantes ou améliorent la convivialité. Dans ce cas encore, il faudra que cela soit justifié par les feedbacks des développeurs, avant d'être approuvé. Les améliorations apportées aux tests et à la documentation quant à elles n'auront pas besoin d'approbation, à condition qu'elles soient identifiées par les labels appropriés noreg-self ou noreg-doc.

Pour en venir aux fonctionnalités de cette version, on peut citer les suivantes :

• JEP 286 - Inférence du type des variables locales, qui vise à améliorer le langage Java pour étendre l'inférence de type aux déclarations de variables locales avec des initialiseurs ;
• JEP 296 - Consolider la JDK Forest dans un référentiel unique. En combinant les nombreux référentiels du JDK Forest dans un référentiel unique, l'objectif est de simplifier et de rationaliser le développement. L'ajout des sources FX au JDK Forest ne fait toutefois pas partie de la proposition ;
• JEP 304 - Interface Garbage-Collector. Ce JEP vise à améliorer l'isolation du code source des différents garbage collectors en introduisant une interface « propre » de garbage collector (GC) ;
• JEP 307 - Récupération de mémoire complètement en parallèle pour le garbage collector G1 : améliorer les pires cas de latence de G1 en implémentant le parallélisme ;
• JEP 310 - Application Class-Data Sharing. L'objectif est de réduire l'empreinte en partageant les métadonnées de classe communes entre les différents processus Java, améliorer le temps de démarrage et étendre la fonctionnalité Class-Data Sharing (CDS) existante pour permettre aux classes d'applications d'être placées dans l'archive partagée ;
• JEP 312 - Introduction d'un moyen d'exécuter un callback sur les threads sans effectuer de safepoint VM global. Des threads individuels pourront être arrêtés au lieu que ça soit seulement possible d'arrêter tous les threads ou aucun thread ;
• JEP 313 - Suppression de l'outil javah du JDK. Cette décision a été motivée par le fait que l'outil a été remplacé par une meilleure fonctionnalité dans javac, ajoutée dans le JDK 8. Cette fonctionnalité permet d'écrire des fichiers d'en-tête natifs au moment de la compilation du code source Java, ce qui élimine le besoin d'un outil distinct ;
• JEP 314 - Amélioration de java.util.Locale et les API associées pour implémenter des extensions Unicode supplémentaires des balises de langue BCP 47. À partir de Java SE 9, les extensions de balises de langue BCP 47 U prises en charge sont ca et nu. Le JEP 314 ajoute le support pour les extensions supplémentaires cu (currency type), fw (first day of week), rg (region override) et tz (time zone) ;
• JEP 316 - Allocation de tas sur d'autres dispositifs de mémoire : permettre à la machine virtuelle HotSpot d'allouer le tas d'objets Java sur un autre périphérique de mémoire, tel qu'un NV-DIMM, spécifié par l'utilisateur ;
• JEP 317 - Compilateur JIT Java expérimental : permettre au compilateur JIT basé sur Java, Graal, d'être utilisé comme compilateur JIT expérimental sur Linux/x64 ;
• JEP 319 - Certificats racines : fournir un ensemble par défaut de certificats d'autorité de certification (CA) racines dans le JDK. L'objectif est d'ouvrir les certificats racines dans le programme Java SE Root CA d'Oracle afin de rendre les builds OpenJDK plus attrayantes pour les développeurs et réduire les différences entre ces builds et les builds Oracle JDK ;
• JEP 322 - Versioning basé sur le temps. Cette décision s'explique par le fait que le modèle de versioning introduit avec le JEP 223 (qui distingue facilement les versions majeures, mineures et de mise à jour de sécurité) n'est plus adapté aux prochaines versions du JDK. Oracle prévoit en effet de livrer de nouvelles versions de la plateforme Java SE et du JDK tous les six mois.

La sortie du JDK 10 est prévue pour le 20 mars 2018.

Mise à jour le 13/02/2018 : la première release candidate du JDK 10 est maintenant disponible

La dernière release candidate du JDK 10 étant attendue pour le 22 février, Oracle vient de publier la première RC. Dans un message dans la liste de diffusion de l’OpenJDK, Mark Reinhold, l’architecte en chef du JDK chez Oracle a annoncé hier qu’il n’y a pas de bogues de priorité P1 non résolus dans la dernière build 43, alors elle sera la première RC du JDK 10. Les binaires sont disponibles en téléchargement ici. Oracle ne va maintenant corriger que les bogues qui sont vraiment critiques pour la sortie du JDK.

Sources : Fonctionnalités du JDK 10, Gel des fonctionnalités du JDK 10, Annonce de la première release candidate du JDK 10

Et vous ?

Êtes-vous déjà passé à Java 9 ? Si oui, qu’en retenez-vous ?
Que pensez-vous de cette nouvelle version ?