- Shenandoah : c’est un ramasse-miettes à faible temps de pause en effectuant le travail d’évacuation simultanée entre les threads Java en cours d’exécution. Les temps de pause sont indépendants de la taille du tas ;
- suite Microbenchmark : c’est un outil pour aider les développeurs à utiliser les microcritères existant déjà dans le code source du JDK ou en créer de nouveaux ;
- expression de commutation : apporte quelques modifications à l’instruction switch pour la rendre plus flexible ;
- API de constantes JVM : permet d’ajouter une API pour les descriptions nominales des principaux artéfacts de classes et de fichiers de classe, en particulier les constantes pouvant être chargées à partir du pool de constantes ;
- un apport AArch64, pas deux : sert à supprimer toutes les sources liées aux arm64port pour permettre à tous les contributeurs de concentrer leurs efforts sur une implémentation ARM 64 bits unique et d’éliminer le travail en double requis par la maintenance de deux ports ;
- archives CDS par défaut : sert à améliorer le processus de génération JDK afin de générer une archive CDS (Class Data Sharing) à l’aide de la liste de classe par défaut sur des plateformes 64 bits ;
- collections mélangées abandonnées pour G1 : permet d’annuler les collections d’éléments lorsqu’elles peuvent dépasser la cible de pause ;
- retournez rapidement la mémoire validée non utilisée de G1 : améliore le récupérateur G1 pour qu’il puisse renvoyer automatiquement la mémoire heap de Java au système d’exploitation lorsqu’il est inactif.
Rappelons que, la seule fonctionnalité annoncée au départ et finalement absente de cette version concerne les littéraux de chaînes bruts. Cette fonctionnalité causait quelques problèmes d’implémentation notamment le choix des délimiteurs et la mauvaise interprétation des séquences d’échappement (\n par exemple). Brian Goetz, architecte Java chez Oracle a justifié l’abandon de cette fonctionnalité en déclarant ce qui suit :
« En examinant les commentaires que nous avons reçus, je ne suis plus convaincue que nous ayons encore trouvé le bon compromis entre complexité et expressivité, ou que nous en avons suffisamment exploré l’espace de conception pour être sûr que la conception actuelle est la meilleure que nous puissions faire. En le retirant, nous pouvons continuer à affiner la conception, explorer plus d'options et viser un aperçu répondant réellement aux exigences du processus de fonction de prévisualisation (JEP 12) ».
Alors, cette fonctionnalité peut-elle réapparaître dans le JDK 13 qui sera également publié en 2019 ? Même si les fonctionnalités d’une version à accès anticipé ne peuvent pas faire l’objet d’une disponibilité générale, Oracle l’a quand même publié pour ouvrir le débat sur les propositions, et des corrections. La note de versions ne présente pas beaucoup d’informations, mais quelques constructions ont été annoncées. Dans cette note, Oracle parle d’unifier deux méthodes de la classe GraphicsEnvironment (getCenterPoint() et getMaximumWindowBounds()) qui sont apparues dans le JDK depuis sa version 1.4. Dans le JDK 13, l’implémentation de ces méthodes est unifiée pour toutes les plateformes (Linux, Mac, Windows et Alpine Linux) et :
- getCenterPoint renvoie les coordonnées du centre de l'affichage principal, pour toutes les plateformes ;
- getMaximumWindowBounds renvoie les limites des insertions d'affichage primaire, pour toutes les plateformes.
La note de version du JDK 13 n’a pas abordé pour l’instant la réinsertion des littéraux de chaînes, mais certains internautes en parlent. Les quelques autres informations disponibles sur cette version à accès anticipé du JDK 13 sont disponibles sur le site de l’OpenJDK.
Source : OpenJDK
Et vous ?
Que pensez-vous du JDK 13 ?
Que proposeriez-vous pour l'intégration des littéraux de chaînes dans JDK 13 éventuellement ?
Êtes-vous pour ou contre cette unification des méthodes de la classe GraphicsEnvironment ? Pourquoi ?
Voir aussi
Java : Oracle publie la première release candidate du JDK 12 avec toutes les fonctionnalités majeures annoncées sauf les littéraux de chaînes bruts
Java : le JDK 12 est disponible en version bêta, il prend en charge Unicode 11 et dispose d'un nouveau format de clé privée codé x25519 et x448
Les littéraux de chaîne bruts ont été supprimés de Java 12 comme l'a suggéré la proposition d'amélioration JDK (JEP)