Cela fait exactement 2 mois depuis la sortie de Java 9, donc selon le nouveau planning, la prochaine version de Java est prévue dans 4 mois. La périmètre complet de Java 10 est toujours confirmé et stable. Cela signifie qu'il existe encore la possibilité de changements significatifs dans le périmètre et le contenu de la version d'ici la version GA. Cependant, il est possible de se faire une idée des fonctionnalités que les développeurs peuvent raisonnablement attendre avec Java 10, dans environ 4 mois.
Les nouvelles fonctionnalités et améliorations sont suivies via le Java Enhancement Process en tant que JEPs ou via Java Community Process pour les demandes de standardisation (JSR). Avec un laps de temps réduit et donc un périmètre restreint, les modifications de Java 10 arriveront en tant que JEP et peuvent être suivies via leur numéro JEP.
Les fonctionnalités que Java 10 semble le plus susceptible de contenir sont celles dont les JEPs sont actuellement dans l'état Ciblé ou Proposé dans la Cible. Actuellement, cela comprend les fonctionnalités suivantes :
- 286 : Inférence de type variable locale
- 296 : Consolider la Forêt du JDK dans un référentiel unique
- 304 : Interface garbage-collector
- 307 : GC complet parallèle pour G1
- 310 : Classe d'application - Partage de données
- 312 : Thread-Handshakes locaux
Parmi ceux-ci, la JEP 296 est purement de l'infrastructure et la JEP 304 améliore l'isolation du code des différents ramasse-miettes et introduit une interface définie pour ceux-ci.
Cela signifie qu'il sera plus facile pour les fournisseurs de produire des builds JDK qui contiennent ou excluent un algorithme GC spécifique. Avec les nouvelles approches du GC telles que Shenandoah, ZGC et Epsilon en développement, cela prend tout son sens. Il y a même des efforts au sein de la communauté pour rendre caduque et même supprimer le ramasse-miettes Concurrent-Mark-Sweep (CMS) bien qu'à l'heure actuelle, il n'y ait pas de remplacement disponible acceptable en production pour cela.
Le changement qui est susceptible de susciter le plus d'intérêt est la JEP 286, qui permettra au développeur de réduire les erreurs dans les déclarations de variables locales en améliorant l'inférence de type. Cela signifie que ce qui suit devient légal Java dès la prochaine version :
var list = new ArrayList<String>(); // infers ArrayList<String>
var stream = list.stream(); // infers Stream<String>
Cette syntaxe sera restreinte à l'initialisation des variables locales, y compris dans les boucles for.
Il ne s'agit là que de sucre syntaxique implémenté dans le compilateur de code source et il n'a aucune signification sémantique. Néanmoins, l'expérience montre que cette fonctionnalité est susceptible de provoquer de vifs débats parmi les développeurs Java.
Les trois changements restants ont tous un impact, quoique potentiellement faible, sur la performance.
La JEP 307 résout un problème avec le ramasse-miettes G1 - à partir de Java 9, l'implémentation actuelle du GC complet pour G1 utilise un algorithme (série) unique.
Cela signifie que si G1 doit revenir à un GC complet, alors il y aura un méchant impact sur les performances. Le but de la JEP 307 est de paralléliser l'algorithme GC complet de sorte que dans le cas improbable d'un GC complet G1, le même nombre de processus pourrait être utilisé comme dans les collectes concurrentes.
La JEP 310 étend une fonctionnalité appelée Partage de Données de Classe (CDS), qui permet à une JVM d'enregistrer un ensemble de classes et de les traiter dans un fichier d'archive partagé. Cette archive peut ensuite être mappée en mémoire dans le processus de la JVM lors de la prochaine exécution afin de réduire le temps de démarrage. Le fichier peut également être partagé entre les machines virtuelles Java et cela peut réduire l'empreinte mémoire globale lorsque plusieurs machines virtuelles Java s'exécutent sur le même hôte.
Cette fonctionnalité existe depuis Java 5, mais depuis Java 9, CDS autorise uniquement le chargeur de classe d'amorçage à charger les classes archivées. Le but de la JEP 310 est d'étendre ceci pour permettre à l'application et aux chargeurs de classe personnalisés d'utiliser des fichiers d'archives. Cette fonctionnalité existe déjà, mais n'est actuellement disponible que dans le JDK Oracle, pas dans l'OpenJDK.
Cette JEP consiste donc essentiellement à déplacer la fonctionnalité dans le repo ouvert depuis les sources Oracle privées ; à partir de Java 10, les versions régulières (non LTS) seront des binaires OpenJDK. Le fait qu'Oracle transfère cette fonctionnalité aux repos ouverts indique qu'ils ont des clients qui l'utilisent en production, et qu'Oracle devra donc les prendre en charge sur un binaire OpenJDK.
Enfin, la JEP 312 jette les bases d'une performance VM améliorée, en permettant d'exécuter un callback sur les processus applicatifs sans effectuer de point de sécurité global à la VM. Cela signifie que la JVM pourrait arrêter des processus spécifiques et non uniquement l'intégralité de ceux-ci. Certaines des petites améliorations de bas niveau que cela permet d'inclure comprennent :
- Réduction de l'impact de l'acquisition d'un échantillon de trace de pile (par exemple pour le profilage).
- Meilleur échantillonnage de trace de pile en réduisant la dépendance aux signaux.
- Amélioration du verrouillage des biais en n'arrêtant que les processus individuels pour annuler ceux-ci.
- Suppression de certaines barrières de mémoire de la JVM.
Dans l'ensemble, il semble que Java 10 ne contienne pas de nouvelles fonctionnalités ou améliorations de performances majeures. C'est peut-être à prévoir - au lieu d'un vaste changement, il représente la première version du nouveau cycle de diffusion, plus fréquent et progressif.