Pour rappel, Java 8 a été rendu disponible en mars 2014 et a apporté de nombreuses fonctionnalités au langage. Il ‘agissait de plus de 56 fonctionnalités ajoutées, notamment les arrivées des expressions lambdas, des méthodes par défaut, des interfaces fonctionnelles et de Stream modifiant en profondeur le langage et donc l'écosystème Java tout entier.Il y avait également l'incorporation d'une nouvelle API pour gérer les dates, de nouvelles annotations et d’un nouveau moteur d'exécution JavaScript. Beaucoup parmi les internautes avaient trouvé ces changements majeurs apportés dans Java 8 très impressionnants. Ils ont déclaré que cette version du langage évoluait lentement pour son époque, mais de façon efficace. Aussi, trouvaient-ils, les expressions lambdas agréables à utiliser.
Quant à Java 11, il est apparu en septembre 2018. Java 11 était une importante mise à jour, puisqu’il s'agissait de la première version LTS (bénéficiant d'un support à long terme) depuis que Oracle a décidé de sortir deux versions de Java par an. Elle était donc destinée aux utilisateurs qui privilégient la stabilité à un accès rapide aux nouvelles fonctionnalités. Dans Java 11, une nouvelle API HTTP fait son apparition. En fait, elle n'est pas tout à fait nouvelle, puisqu'elle a été introduite dans le JDK 9 (en incubation) et mise à jour dans le JDK 10. L'API HTTP a été standardisée dans Java 11. Dans le cadre de ce travail, l'API précédemment incubée, qui se trouvait dans le package jdk.incubator.http, a été supprimée.
Les résultats des différents tests réalisés ont été rapportés dans un billet de blog par Radovan Synek, ingénieur qualité à OptaPlanner. Pour réaliser ces tests, dit-il, ils ont utilisé :
- une machine stable sans aucun autre processus de calcul en cours d'exécution, avec 2 x Intel® Xeon® CPU E5-2609 0 @ 2.4 GHz (8 cores total) et 31.3 Go de mémoire RAM, exécutant RHEL 6.
- les versions des ramasse-miettes G1 et Parallel GC des deux versions Java permettent de comparer l’impact de la récupération de place. Java est exécuté avec les paramètres -Xmx1536M -server -XX:+UseG1GC et -Xmx1536M -server -XX:+UseParallelGC respectivement ;
- Oracle Java 8 : la version java "1.8.0_191" ; un environnement d'exécution Java SE (version 1.8.0_191-b12) ; un ordinateur virtuel Java HotSpot (TM) 64 bits (version 25.191-b12, mode mixte) ;
- et OpenJDK 11 : openjdk version "11.0.1" 2018-10-16 ; OpenJDK Runtime Environment 18.9 (version 11.0.1 + 13) ; OpenJDK 64-Server VM 18.9 (version 11.0.1 + 13, mode mixte) ;
La version de OptaPlanner utilisée est la version 7.14.0.Final et les indications données sont :
- la résolution d'un problème de planification n'implique aucune entrée/sortie (à l'exception de quelques millisecondes au démarrage pour charger l'entrée) ;
- un seul processeur est complètement saturé. Il crée constamment de nombreux objets éphémères que le GC collecte ensuite. Chaque exécution résout 11 problèmes de planification avec OptaPlanner ;
- Chaque problème de planification dure 5 minutes et commence par un préchauffage de la JVM de 30 secondes, qui est ignoré ;
- les repères mesurent le nombre de scores calculés par milliseconde. Le calcul d'un score pour une solution de planification proposée est non trivial : il implique de nombreux calculs, y compris la recherche de conflits entre chaque entité et toutes les autres entités.
Les résultats de comparaison entre Java 11 et Java 8 en utilisant le ramasse-miettes G1 montrent que presque tous les ensembles de données améliorent Java 11 par rapport à Java 8 en utilisant le collecteur de déchets G1. En moyenne, le passage à Java 11 représente une amélioration de 16 %. Une explication possible de cette amélioration pourrait être le JEP 307 Parallel Full GC pour G1 introduit dans Java 10 pour améliorer les pires latences du collecteur G1. L'un des principaux avantages de G1 est sa capacité à compacter de l'espace mémoire libre sans temps de pause prolongés. Il peut également retirer des tas inutilisés.
Une autre comparaison faite est celle entre le GC parallèle contre le G1 sur Java 11 uniquement. Cette dernière donne ce qui suit : Bien que G1 montre une nette amélioration par rapport à Java 8, la stratégie du G1 pour OptaPlanner est moins avantageuse pour le GC parallèle que pour la plupart des jeux de données. La seule exception est la réassignation de machine, qui montre que OptaPlanner G1 est capable de calculer plus rapidement. Le GC parallèle est un GC à haut débit utilisé par défaut dans JDK8. En même temps, cela ne convient pas à la réduction de la mémoire, ce qui la rend inappropriée pour une mise à l'échelle verticale flexible. D’après les tests donc, Java 11 semble plus rapide avec sa manière de gérer la mémoire.
« Java 11 apporte des améliorations supplémentaires, qui varient selon les exemples et les ensembles de données OptaPlanner. En moyenne, il est 4,5 % plus rapide avec Parallel GC et 16,1 % plus rapide avec G1. Malgré l'amélioration significative du PGC G1, le PGC parallèle reste plus rapide pour la plupart des ensembles de données de ce point de référence », a écrit Radovan pour conclure.
Source : OptaPlanner
Et vous ?
Êtes-vous un développeur Java, que pensez-vous de ces résultats ?
Java 11 vous paraît-il vraiment plus rapide que Java 8 ? Pourquoi ?
Voir aussi
Java 8 est disponible, la plate-forme se met aux expressions lambdas, tour d'horizon des nouveautés
Oracle annonce la sortie officielle de Java 11 : tour d'horizon des principales nouveautés de cette version LTS
JDK 10 : les fonctionnalités de la prochaine version de Java sont désormais gelées, la sortie est attendue pour le 20 mars 2018
Java 8 ne va plus recevoir de mises à jour et correctifs de sécurité à partir de septembre à moins de passer à un support commercial