1 pièce(s) jointe(s)
Oracle rétropédale en rendant son JDK 17 accessible sans coût pour une utilisation commerciale
JDK 17 : Java 17 sera une version LTS et ses nouveautés incluent un nouveau pipeline de rendu pour macOS
et une API uniforme pour les générateurs de nombres pseudo-aléatoires
Environ un mois après qu'Oracle a annoncé la disponibilité générale du JDK 16 (Java 16), son successeur, le JDK 17 a déjà commencé par prendre forme. Bien qu'il ne soit pas prévu avant septembre, cinq des nouvelles fonctionnalités prévues pour être intégrées à Java 17 sont déjà connues. L'un des changements annoncés prévoit de supprimer le compilateur expérimental AOT (ahead-of-time) et JIT (just-in-time) basé sur Java. Java 17 sera une version de support à long terme (LTS), il apportera un nouveau pipeline de rendu pour macOS et une API uniforme pour les générateurs de nombres pseudo-aléatoires est également prévue.
Oracle a publié Java 16 avec 17 nouveautés visant à améliorer la productivité des développeurs. Cette version du JDK a été livrée avec la finalisation des enregistrements et du filtrage par motif (Pattern Matching) pour l'opérateur instanceof, et quelques améliorations du langage présentées en préversion dans Java 14. Les développeurs pourront également utiliser le nouvel outil de packaging pour livrer des applications Java autocontenues, mais aussi découvrir trois interfaces de programmation en incubation : l'API Vecteur, l'API d'édition de liens étrangers et l'API d'accès à la mémoire étrangère.
Il y a en outre une fonctionnalité qui est disponible en préversion : les classes scellées. La deuxième version annuelle du JDK, notamment le JDK 17, est prévue pour le mois de septembre prochain et intégrera les nouveautés suivantes :
Suppression du compilateur AOT et JIT (JEP 410)
Selon l'équipe du JDK, le compilateur expérimental AOT et JIT a été très peu utilisé, mais nécessite un effort de maintenance important. Le plan prévoit de maintenir l'interface du compilateur de la JVM au niveau Java afin que les développeurs puissent continuer à utiliser des versions du compilateur construites en externe pour la compilation JIT. La compilation AOT (l'outil jaotc) a été intégrée au JDK 9 en tant que fonctionnalité expérimentale. Cet outil utilise le compilateur Graal, qui est lui-même écrit en Java, pour la compilation AOT.
Ces fonctionnalités expérimentales n'ont pas été incluses dans les constructions du JDK 16 publiées par Oracle il y a quelques semaines. Selon le plan annoncé, trois modules JDK seraient supprimés : jdk.aot (l'outil jaotc) ; internal.vm.compiler, le compilateur Graal ; et jdk.internal.vm.compiler.management, le MBean Graal. Le code HotSpot lié à la compilation AOT serait également supprimé.
Un nouveau pipeline de rendu macOS (JEP 382)
La JEP 382 prévoit d'ajouter au langage un nouveau pipeline de rendu pour macOS, utilisant l'API Apple Metal comme alternative au pipeline existant qui utilise l'API OpenGL dépréciée. Cette proposition vise à fournir un pipeline de rendu entièrement fonctionnel pour l'API Java 2D et qui utilise le framework Metal de macOS. Selon l'équipe du JDK, cela est nécessaire au cas où Apple supprimerait l'API OpenGL d'une future version de macOS. Le pipeline devrait avoir une parité fonctionnelle avec le pipeline OpenGL existant, avec des performances aussi bonnes ou meilleures dans certaines applications et certains benchmarks.
Une architecture propre serait créée et s'intégrerait dans le modèle Java 2D actuel. Le pipeline coexisterait avec le pipeline OpenGL jusqu'à son obsolescence. L'objectif de la proposition n'est pas d'ajouter de nouvelles API Java ou JDK.
Portage du JDK sur macOS/AArch64 (JEP 391)
La JEP 391 est un projet de portage du JDK sur macOS/AArch64 en réponse au projet d'Apple de faire passer ses ordinateurs Macintosh de x64 à AArch64. Un portage AArch64 de Java existe déjà pour Linux et des travaux sont en cours pour Windows. Les développeurs Java s'attendent à réutiliser le code AArch64 existant de ces ports en employant la compilation conditionnelle, comme c'est la norme dans les ports du JDK, pour tenir compte des différences dans les conventions de bas niveau telles que l'interface binaire de l'application et l'ensemble des registres réservés du processeur.
Les changements pour macOS/AArch64 risquent de casser les ports existants Linux/AArch64, Windows/AArch64, et macOS/x64, mais le risque devrait être réduit par des tests de préintégration.
Générateurs de nombres pseudo-aléatoires (JEP 356)
La JEP 356 prévoit des générateurs de nombres pseudo-aléatoires améliorés qui fourniraient de nouveaux types d'interfaces et d'implémentations pour les générateurs de nombres pseudo-aléatoires (PRNG – pseudorandom number generators), y compris les PRNG sautables et une classe supplémentaire d'algorithmes PRNG divisibles (LXM). Selon cette proposition, une nouvelle interface, RandomGenerator, fournira une API uniforme pour tous les PRNG existants et nouveaux. Quatre interfaces RandomGenerator spécialisées seront fournies.
Ce plan est motivé par l'accent mis sur de nombreux aspects à améliorer dans le domaine de la génération de nombres pseudo-aléatoires en Java. L'effort ne prévoit pas de fournir des implémentations de nombreux autres algorithmes PRNG. Mais trois algorithmes communs ont été ajoutés, qui sont déjà largement déployés dans d'autres environnements de langage de programmation. Les objectifs du plan sont les suivants :
- faciliter l'utilisation de divers algorithmes PRNG de manière interchangeable dans les applications ;
- améliorer la prise en charge de la programmation basée sur les flux, en fournissant des flux d'objets PRNG ;
- éliminer la duplication de code dans les classes PRNG existantes ;
- préserver le comportement existant de la classe java.util.Random.
Dépréciation de l'API Applet pour suppression (JEP 398)
Selon l'équipe du JDK, cette API est essentiellement sans intérêt, puisque tous les fournisseurs de navigateurs Web ont supprimé la prise en charge des plug-ins de navigateur Java ou ont annoncé leur intention de le faire. L'API Applet a déjà été dépréciée, mais pas pour être supprimée, dans Java 9 en septembre 2017.
Source : JDK (Java) 17
Et vous ?
:fleche: Que pensez-vous des nouvelles fonctionnalités de Java 17 ?
Voir aussi
:fleche: Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
:fleche: Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors, et supprimera le moteur JavaScript Nashorn
:fleche: Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
:fleche: Marquée obsolète depuis 2016, l'API Applet sera bientôt définitivement supprimée de Java. Y a-t-il des raisons de regretter les applets Java ?
:fleche: Java : Oracle va marquer l'API Applet obsolète dans le JDK 9, mais n'a pas l'intention de la supprimer de sitôt
1 pièce(s) jointe(s)
JDK 17 est en disponibilité générale, la première version LTS depuis JDK 11 il y a trois ans
JDK 17 est en disponibilité générale, la première version LTS depuis JDK 11 il y a trois ans
s'accompagne de 14 JEP
Une nouvelle version de Java paraît tous les six mois, en mars et en septembre. Selon le cycle de vie du support d'Oracle Java SE, ceux-ci ne sont pris en charge que pendant six mois jusqu'à ce que la prochaine version apparaisse, tandis que les versions LTS sont prises en charge pendant huit ans.
Java 8 (la dernière avant une refonte majeure du JDK dans Java 9 avec de nombreuses modifications de rupture) a étendu la prise en charge jusqu'en décembre 2030, tandis que la prise en charge étendue de Java 11 s'étend jusqu'en septembre 2026.
Les fournisseurs d'éditions OpenJDK ouvertes de Java font en général des correspondance en terme de prise en charge. Il arrive qu'ils dépassent parfois ces dates de support, mais seules les éditions LTS sont destinées à une utilisation à long terme.
Quoi de neuf dans JDK 17 ?
Dans une liste de diffusion, il est expliqué que cette version comprend quatorze JEP (Java Enhancement Proposal):
- Restaurer une sémantique à virgule flottante toujours stricte (JEP 306)
- Générateurs de nombres pseudo-aléatoires améliorés (JEP 356)
- Nouveau pipeline de rendu macOS (JEP 382)
- portage du JDK sur macOS/Aarch64 (JEP 391)
- Dépréciation de l'API Applet pour suppression (JEP 398)
- Encapsuler fortement les composants internes du JDK (JEP 403)
- Pattern Matching pour switch (Preview, JEP 406)
- Suppression de l'activation RMI (JEP 407)
- Classes scellées (JEP 409)
- Suppression du compilateur expérimental AOT et JIT (JEP 410)
- Dépréciation du gestionnaire de sécurité pour la suppression (JEP 411)
- API de fonction étrangère et de mémoire (incubateur, JEP 412)
- API vectorielle (deuxième incubateur, JEP 414)
- Filtres de désérialisation spécifiques au contexte (JEP 415)
ainsi que des centaines d'améliorations plus petites et près de deux mille corrections de bugs.
Pour mémoire, un JEP est un document qui propose une amélioration de la technologie de base de Java. Ces propositions concernent généralement des améliorations qui ne sont pas encore prêtes à être spécifiées.
Les classes scellées (JEP 409)
Les classes scellées, qui ont été disponibles en préversion dans Java 15, restreignent les types qui peuvent en hériter. En Java, une classe scellée a une clause allows qui spécifie les sous-classes autorisées, comme dans*:
Code:
1
2
| public abstract sealed class Shape
permits Circle, Rectangle, Square { ... } |
Suppression du compilateur AOT (ahead-of-time) et JIT (just-in-time) (JEP 410)
Selon l'équipe du JDK, le compilateur expérimental AOT et JIT a été très peu utilisé, mais nécessite un effort de maintenance important. Il est prévu de maintenir l'interface du compilateur de la JVM au niveau Java afin que les développeurs puissent continuer à utiliser des versions du compilateur construites en externe pour la compilation JIT. La compilation AOT (l'outil jaotc) a été intégrée au JDK 9 en tant que fonctionnalité expérimentale. Cet outil utilise le compilateur Graal, qui est lui-même écrit en Java, pour la compilation AOT.
Les mainteneurs avaient déjà annoncé plus tôt cette année que trois modules JDK seraient supprimés : jdk.aot (l'outil jaotc) ; internal.vm.compiler, le compilateur Graal ; et jdk.internal.vm.compiler.management, le MBean Graal. Le code HotSpot lié à la compilation AOT sera également supprimé.
Le compilateur HotSpot Just-in-time existe toujours et ceux qui souhaitent utiliser la compilation AOT ont été dirigés vers Graal.
Un nouveau pipeline de rendu macOS (JEP 382)
La JEP 382 prévoit d'ajouter au langage un nouveau pipeline de rendu pour macOS, utilisant l'API Apple Metal comme alternative au pipeline existant qui utilise l'API OpenGL dépréciée. Cette proposition vise à fournir un pipeline de rendu entièrement fonctionnel pour l'API Java 2D et qui utilise le framework Metal de macOS. Selon l'équipe du JDK, cela est nécessaire au cas où Apple supprimerait l'API OpenGL d'une future version de macOS. Le pipeline devrait avoir une parité fonctionnelle avec le pipeline OpenGL existant, avec des performances aussi bonnes ou meilleures dans certaines applications et certains benchmarks.
Une architecture propre serait créée et s'intégrerait dans le modèle Java 2D actuel. Le pipeline coexisterait avec le pipeline OpenGL jusqu'à son obsolescence. L'objectif de la proposition n'est pas d'ajouter de nouvelles API Java ou JDK.
Portage du JDK sur macOS/AArch64 (JEP 391)
La JEP 391 est un projet de portage du JDK sur macOS/AArch64 en réponse au projet d'Apple de faire passer ses ordinateurs Macintosh de x64 à AArch64. Un portage AArch64 de Java existe déjà pour Linux et des travaux sont en cours pour Windows. Les développeurs Java s'attendent à réutiliser le code AArch64 existant de ces ports en employant la compilation conditionnelle, comme c'est la norme dans les ports du JDK, pour tenir compte des différences dans les conventions de bas niveau telles que l'interface binaire de l'application et l'ensemble des registres réservés du processeur.
Les changements pour macOS/AArch64 risquent de casser les ports existants Linux/AArch64, Windows/AArch64, et macOS/x64, mais le risque devrait être réduit par des tests de préintégration.
Générateurs de nombres pseudo-aléatoires (JEP 356)
La JEP 356 prévoit des générateurs de nombres pseudo-aléatoires améliorés qui fourniraient de nouveaux types d'interfaces et d'implémentations pour les générateurs de nombres pseudo-aléatoires (PRNG – pseudorandom number generators), y compris les PRNG sautables et une classe supplémentaire d'algorithmes PRNG divisibles (LXM). Selon cette proposition, une nouvelle interface, RandomGenerator, fournira une API uniforme pour tous les PRNG existants et nouveaux. Quatre interfaces RandomGenerator spécialisées seront fournies.
Cette décision est motivée par l'accent mis sur de nombreux aspects à améliorer dans le domaine de la génération de nombres pseudo-aléatoires en Java. L'effort ne prévoit pas de fournir des implémentations de nombreux autres algorithmes PRNG. Mais trois algorithmes communs ont été ajoutés, qui sont déjà largement déployés dans d'autres environnements de langage de programmation. Les objectifs de cette stratégie sont les suivants :
- faciliter l'utilisation de divers algorithmes PRNG de manière interchangeable dans les applications ;
- améliorer la prise en charge de la programmation basée sur les flux, en fournissant des flux d'objets PRNG ;
- éliminer la duplication de code dans les classes PRNG existantes ;
- préserver le comportement existant de la classe java.util.Random.
Dépréciation de l'API Applet pour suppression (JEP 398)
Selon l'équipe du JDK, cette API est essentiellement sans intérêt, puisque tous les fournisseurs de navigateurs Web ont supprimé la prise en charge des plug-ins de navigateur Java ou ont annoncé leur intention de le faire. L'API Applet a déjà été dépréciée, mais pas pour être supprimée, dans Java 9 en septembre 2017.
Source : annonce de la disponibilité, note de version
Voir aussi
:fleche: Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
:fleche: Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors, et supprimera le moteur JavaScript Nashorn
:fleche: Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
:fleche: Marquée obsolète depuis 2016, l'API Applet sera bientôt définitivement supprimée de Java. Y a-t-il des raisons de regretter les applets Java ?
:fleche: Java : Oracle va marquer l'API Applet obsolète dans le JDK 9, mais n'a pas l'intention de la supprimer de sitôt
Oracle JDK est désormais disponible gratuitement, y compris toutes les mises à jour de sécurité trimestrielles
Java 17 : Oracle JDK est désormais disponible gratuitement, y compris toutes les mises à jour de sécurité trimestrielles
et même pour une utilisation commerciale et en production
Oracle met gratuitement à disposition Oracle JDK pour tous, y compris toutes les mises à jour de sécurité trimestrielles, sous une nouvelle licence baptisée « Oracle No-Fee Terms and Conditions » (NFTC). La nouvelle licence du JDK Oracle permet une utilisation gratuite pour tous les utilisateurs, même une utilisation commerciale et en production. La redistribution est autorisée tant qu'elle n'est pas payante. Les développeurs et les organisations peuvent désormais facilement télécharger, utiliser, partager et redistribuer le JDK Oracle ; et les versions LTS d'Oracle JDK sous NFTC seront prises en charge pendant au moins un an après la version LTS suivante. Ce changement entre en vigueur à partir de Java 17. Oracle continuera à fournir les versions d'Oracle OpenJDK sous GPL sur le même cycle de publication que depuis Java 9.
En septembre 2017, Oracle a introduit un certain nombre de changements pour Java SE, dont deux versions par an et une licence GPL pour l'OpenJDK. Oracle a en effet annoncé son intention de distribuer l'OpenJDK sous licence GPL avec le nom « Oracle OpenJDK », mais aussi sous licence Oracle Technology Network (OTN) avec le nom « Oracle JDK ». En livrant des versions OpenJDK sous licence GPLv2, Oracle voulait permettre aux développeurs de les distribuer facilement et librement avec leurs frameworks et applications.
Parmi les changements annoncés, on notait également le passage en open source de fonctionnalités commerciales telles que Java Flight Recorder, auparavant uniquement disponibles dans le JDK Oracle. Oracle a aussi promis d'ouvrir un certain nombre de projets internes supplémentaires après avoir discuté avec les contributeurs d'OpenJDK ; c'est ce qui a d'ailleurs été fait. L'objectif était de faire en sorte qu'à termes, il n'y ait plus aucune différence technique entre les versions OpenJDK et les binaires Oracle JDK.
Ces changements, en particulier le fait de fournir des versions d'Oracle OpenJDK sous GPL ont été très bien accueillis, mais les développeurs, universitaires et entreprises voulaient bien plus : que le solide et fiable Oracle JDK soit également disponible sous une licence gratuite sans ambiguïté. Dans Java 17 qui est désormais généralement disponible, Oracle satisfait à cette demande de la communauté en annonçant le passage du JDK Oracle sous la licence gratuite « Oracle No-Fee Terms and Conditions » (NFTC).
Oracle met gratuitement à disposition Oracle JDK pour tous, y compris toutes les mises à jour de sécurité trimestrielles, et même pour une utilisation commerciale et en production. La redistribution est autorisée tant qu'elle n'est pas payante. Sous la licence NFTC, Oracle prendra en charge les versions d'Oracle JDK LTS pendant au moins un an après la version LTS suivante. Cela offre donc aux développeurs plus de flexibilité pour la planification de leur mise à niveau. Ils peuvent toujours suivre la cadence de publication semestrielle du JDK pour bénéficier d'un accès plus rapide aux nouvelles fonctionnalités, améliorations de performances et autres améliorations. Mais ils disposent désormais également du temps nécessaire pour migrer d'un Oracle JDK LTS à un autre, si c'est le modèle qu'ils préfèrent.
Ce changement entre en vigueur à partir de Java 17 et ne concerne pas les versions antérieures. Notons qu'Oracle continuera à fournir les versions d'Oracle OpenJDK sous GPL sur le même cycle de publication que depuis Java 9. L'abonnement Oracle Java SE continuera également de fournir des fonctionnalités à valeur ajoutée telles que le Java Management Service, Advanced Management Console et GraalVM Enterprise sans frais supplémentaires. Il restera donc une option privilégiée pour les organisations qui ont besoin de ces fonctionnalités et d'une assistance 24h/24 et 7j/7. A part ces organisations, tous les autres types d'utilisateurs du JDK devraient trouver intéressant d'utiliser l'Oracle JDK sous la licence NFTC.
Source : Oracle
Et vous ?
:fleche: Ne pensez-vous pas qu'Oracle a rendu Java plus ouvert et maintenable avec les changements entamés depuis septembre 2017 ?
:fleche: Y a-t-il aujourd'hui encore un intérêt à utiliser OpenJDK au lieu du JDK Oracle ?
Voir aussi
:fleche: Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
:fleche: Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors, et supprimera le moteur JavaScript Nashorn
:fleche: Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
:fleche: Marquée obsolète depuis 2016, l'API Applet sera bientôt définitivement supprimée de Java. Y a-t-il des raisons de regretter les applets Java ?
:fleche: Java : Oracle va marquer l'API Applet obsolète dans le JDK 9, mais n'a pas l'intention de la supprimer de sitôt
7 pièce(s) jointe(s)
À quel point Java 17, la dernière version du langage, est-il plus rapide ?
À quel point Java 17, la dernière version du langage, est-il plus rapide ?
Voici une comparaison avec Java 11 et Java 16
Oracle a publié le JDK 17 (ou Java 17) le 14 septembre. Le JKD 17 constitue la dernière version du langage de programmation et elle a été livrée avec de nombreuses nouvelles fonctionnalités et améliorations, mais également une amélioration significative des performances. La plupart des nouvelles fonctionnalités nécessitent des modifications du code pour en bénéficier. Sauf pour les performances. Il suffit de changer votre installation JDK pour bénéficier gratuitement d'une amélioration des performances. Mais de combien ? Cela en vaut-il la peine ? Voici une comparaison des benchmarks du JDK 17, JDK 16 et JDK 11.
Java 17 est une version LTS (Long-Term Support) et Oracle a expliqué que le JDK 17 et les futures versions sont fournis sous une licence gratuite jusqu'à une année complète après la prochaine version LTS. Oracle continuera également à fournir les versions d'Oracle OpenJDK sous la licence publique générale (GPL), comme c'est le cas depuis 2017. La nouvelle version apporte des milliers de mises à jour de performance, de stabilité et de sécurité, ainsi que 14 JEP (JDK Enhancement Proposals) pour améliorer le langage et la plateforme Java. Le JDK 16 a été publié en mars et la version LTS actuelle est le JDK 11, publiée il y a trois ans.
Les améliorations du langage comprennent l'ajout de la prise en charge des classes scellées. Les classes et interfaces scellées limitent les autres classes ou interfaces qui peuvent les étendre ou les mettre en œuvre. Ce développement s'inscrit dans le cadre du projet Amber, qui sert à explorer et à incuber de petites fonctionnalités du langage Java axées sur la productivité. Les autres JEP concernent principalement des mises à jour et des améliorations apportées aux bibliothèques. Dans les notes de version du JDK 17, Oracle a précisé que cette version a réincorporé la sémantique stricte de la virgule flottante.
Dans la version 1.2 de Java, de petites variations dans la sémantique stricte de la virgule flottante étaient autorisées par défaut pour tenir compte des limitations des architectures matérielles de l'époque. Comme cela n'est plus utile ou nécessaire, les écarts ont été supprimés. Parmi les autres améliorations, citons la prise en charge de macOS, avec un nouveau pipeline de rendu macOS et un port macOS aArch64 qui porte le JDK sur la plateforme macOS/AArch64. Ce portage permettra aux applications Java de s'exécuter en mode natif sur les nouveaux ordinateurs Apple Silicon basés sur la technologie Arm 64.
Alors, à quel point Java 17 est-il plus rapide par rapport à Java 11 et Java 16 ? Les benchmarks du JDK 17, JDK 16 et JDK 11 ont été réalisés par Geoffrey De Smet, responsable et fondateur d'OptaPlanner, le principal solveur de contraintes open source IA en Java. OptaPlanner est utilisé dans le monde entier en production par les développeurs des entreprises de l'index Fortune 500, les gouvernements, les startups et les organisations bénévoles à but non lucratif.
Méthodologie des benchmarks
Matériel
Le matériel utilisé est une machine stable sans aucun autre processus exigeant des calculs, avec un processeur Intel® Xeon® Silver 4116 @ 2.1 GHz (12 cœurs au total/24 threads) et 128 Go de mémoire RAM, exécutant RHEL (Red Hat Linux Enterprise) 8 x86_64.
JDK (utilisés pour la compilation et l'exécution) :
Code:
1
2
3
4
|
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment Temurin-11.0.12+7 (build 11.0.12+7)
OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (build 11.0.12+7, mixed mode) |
Code:
1
2
3
4
|
openjdk 16.0.2 2021-07-20
OpenJDK Runtime Environment (build 16.0.2+7-67)
OpenJDK 64-Bit Server VM (build 16.0.2+7-67, mixed mode, sharing) |
Code:
1
2
3
4
|
openjdk 17 2021-09-14
OpenJDK Runtime Environment (build 17+35-2724)
OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing) |
Options JVM
- -XX:+UseG1GC pour G1GC, le ramasse-miettes à faible latence (la valeur par défaut dans les trois JDK) ;
- -XX:+UseParallelGC pour ParallelGC, le ramasse-miettes à haut débit.
Classe principale
La classe principale est org.optaplanner.examples.app.GeneralOptaPlannerBenchmarkApp du module [C]optaplanner-examples[C] dans OptaPlanner 8.10.0.Final.
- chaque exécution résout 11 problèmes de planification avec OptaPlanner, tels que l'affectation des employés, l'aménagement du temps scolaire et l'optimisation du cloud. Chaque problème de planification s'exécute pendant 5 minutes. La journalisation est réglée sur INFO. Le benchmark commence par un réchauffement de la JVM de 30 secondes, qui est supprimé ;
- 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 les données d'entrée). Un seul CPU est complètement saturé. Il crée constamment de nombreux objets à courte durée de vie, et le GC les collecte ensuite ;
- les benchmarks mesurent le nombre de scores calculés par seconde. Plus il est élevé, mieux c'est. Le calcul d'un score pour une solution de planification proposée n'est pas trivial : il implique de nombreux calculs, y compris la vérification des conflits entre chaque entité et chaque autre entité.
Exécutions
Chaque combinaison de JDK et d'éboueur est exécutée 3 fois séquentiellement. Les résultats ci-dessous sont la moyenne de ces 3 exécutions.
Java 11 (LTS) et Java 16 contre Java 17 (LTS)
Note : En regardant les données brutes des 3 exécutions individuelles (non montrées ici), les nombres de réaffectations de la machine (B1 et B10) fluctuent beaucoup entre les exécutions sur le même JDK et GC. Souvent de plus de 10%. Les autres chiffres ne souffrent pas de ce manque de fiabilité. Selon Geoffrey, il est sans doute préférable d'ignorer les chiffres de réaffectation des machines, mais pour éviter les problèmes de sélection des données, ces résultats et moyennes les incluent.
G1GC contre ParallelGC sur Java 17
Conclusion
En moyenne, pour les cas d'utilisation d'OptaPlanner, ces benchmarks indiquent que :
- Java 17 est 8,66 % plus rapide que Java 11 et 2,41 % plus rapide que Java 16 pour G1GC (par défaut) ;
- Java 17 est 6,54 % plus rapide que Java 11 et 0,37 % plus rapide que Java 16 pour ParallelGC ;
- Le collecteur d'ordures ParallelGC est 16,39 % plus rapide que le collecteur d'ordures G1GC.
Ainsi donc, il n'y a pas de grandes surprises ici : le dernier JDK est plus rapide et le collecteur d'ordures à haut débit est plus rapide que le collecteur d'ordures à faible latence. Toutefois, Geoffrey a déclaré que lorsqu'il a évalué le JDK 15, il a constaté que Java 15 était 11,24 % plus rapide que Java 11. Maintenant, le gain de Java 17 par rapport à Java 11 est moindre. Cela signifie-t-il que Java 17 est plus lent que Java 15 ?
« Eh bien, non. Java 17 est aussi plus rapide que Java 15. Ces précédents benchmarks ont été exécutés sur une base de code différente (OptaPlanner 7.44 au lieu de 8.10). Il ne faut pas comparer des pommes et des oranges. En conclusion, les performances gagnées dans la version JDK17 valent bien la mise à niveau - au moins pour les cas d'utilisation d'OptaPlanner », a déclaré Geoffrey. En outre, les données qu'il a présentées montrent que le ramasse-miettes le plus rapide pour ces cas d'utilisation est toujours ParallelGC, au lieu de G1GC (par défaut).
Source : Geoffrey De Smet
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous de cette comparaison entre le JDK 11, le JDK 16 et le JDK 17 ?
Voir aussi
:fleche: JDK 17, l'implémentation de référence de Java 17, est en disponibilité générale. La première version LTS depuis JDK 11 il y a trois ans s'accompagne de 14 JEP
:fleche: Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
:fleche: Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors, et supprimera le moteur JavaScript Nashorn
:fleche: Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
:fleche: La version définitive du JDK 13 est publiée avec la prise en charge d'Unicode 12.1 et de nombreuses améliorations
graphiques sans explication
J'avais un prof qui mettait zéro s'il n'y avait pas de légende à un graphique
ici on nous balance des tests sans savoir ce qu'ils font (même la source ne le dit pas)
les tests B1 et le B10 sont intéressant car ils montrent une régression, malheureusement on reste sur sa faim ... zéro à Geoffrey
2 pièce(s) jointe(s)
Oracle rétropédale en rendant son JDK 17 accessible sans coût pour une utilisation commerciale
Oracle rétropédale en rendant son JDK 17 accessible sans coût pour une utilisation commerciale en raison de son abandon par les acteurs du développement informatique
Qui lui préfèrent l’openJDK
La décision d’Oracle est-elle tardive ? Peut-on s’y fier en raison de la complexité des termes de la nouvelle licence « Oracle No-Fee Terms and Conditions » (NFTC) ? Quel impact sur l’avenir de sa version du kit de développement Java (JDK) ? Des sondages suggèrent que les distributions JDK d'Oracle ne sont plus les plus populaires dans la filière du développement informatique. Les développeurs semblent préférer les distributions OpenJDK de AdoptOpenJDK (maintenant Eclipse Temurin), Amazon, Microsoft, Azul et d'autres éditeurs.
L'édition 2021 du rapport de l'écosystème JVM révèle que 62 % (d'un échantillon de 2000) des développeurs interrogés utilisent Java 11 en production. Java 8 arrive en seconde position avec 60 %. Kotlin est le langage JVM le plus populaire après Java. AdoptOpenJDK est la distribution JDK la plus populaire avec 45 % des retours en sa faveur. Elle apparaît dans les résultats de ce sondage loin devant Oracle OpenJDK et Oracle JDK, avec respectivement 28 % et 23 %. Grosso modo, le tableau est celui d’une réorientation des intervenants de la filière du développement informatique vers la version libre du kit de développement Java.
La faute aux zones d’ombre au sein de la NFTC ?
La décision d'Oracle de commencer à faire payer pour l’accès à son JDK en 2018 a entraîné une incertitude et une confusion considérables dans la communauté Java. C’est la raison pour laquelle Java a réagi avec l’annonce de la disponibilité sans coût de la version 17 du JDK. Le diable se cache dans les détails y relatifs.
La licence stipule tout d’abord que l'utilisation d'Oracle JDK 17 est régie par la NFTC. En d'autres termes, si une entreprise dispose déjà d'une licence pour les programmes Oracle Java (par exemple, par le biais d'un abonnement à Oracle Java Standard Edition ou dans le cadre d'une autre licence Oracle (par exemple, Oracle Weblogic), son déploiement et son utilisation d'Oracle JDK 17 ne sont pas régis par la NFTC. Cette disposition impacte sur certains des droits d’utilisation.
En effet, la licence donne le droit à l’utilisateur du JDK 17 d’en faire un usage interne à des fins de développement, de test, de prototypage et de démonstration de ses applications. Ce droit avait déjà fait l'objet d'accord par Oracle pour les versions précédentes de son JDK dans le cadre de son contrat de licence OTN - Oracle Technology Network. En d'autres termes, l’utilisation du JDK 17 n’est pas permise sous la NFTC pour le développement des applications qu’un tiers ne développe pas ou ne possède pas en tant qu’entreprise.
Nouveauté à la clé : si une organisation souhaite déployer et faire usage du JDK 17 en son sein, elle n’est pas soumise à l’obligation de faire l’acquisition d’une nouvelle licence. Néanmoins, cette disposition devient invalide si l’utilisation du JDK 17 est déjà régie par un autre contrat de licence Java.
Oracle se basera sur la NFTC pour son JDK 17 et les versions ultérieures. Les versions LTS, telles que JDK 17, recevront des mises à jour sous cette licence pendant un an après la sortie de la version LTS suivante. Après la période de licence d'utilisation gratuite, Oracle a l'intention d'utiliser la licence OTN, la même que celle actuellement utilisée pour les versions LTS de Java 8 et 11, pour les mises à jour ultérieures.
Au-delà de cette période, si une entreprise souhaite obtenir d'autres mises à jour Java 17 passé cette date, elle doit passer à la souscription Oracle Java SE et revenir à l'accord de licence OTN. Autre alternative : passer à la prochaine version LTS tous les deux ans.
Sources : Rapport JVM, Oracle
Et vous ?
:fleche: Oracle est-il crédible ? Comprenez-vous la décision de cette entreprise de proposer une version payante de son JDK pour une utilisation commerciale ?
:fleche: Quelles sont les raisons pour lesquelles le JDK d’Oracle demeure incontournable ?
:fleche: Quels sont les ingrédients du JDK d’Oracle qui continuent à manquer à l’appel dans l’openJDK ?
Voir aussi :
:fleche: Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
:fleche: Java 15 est déjà sur les rails : la prochaine version standard ajoutera des blocs de texte et des Garbage Collectors, et supprimera le moteur JavaScript Nashorn
:fleche: Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
:fleche: Marquée obsolète depuis 2016, l'API Applet sera bientôt définitivement supprimée de Java. Y a-t-il des raisons de regretter les applets Java ?
:fleche: Java : Oracle va marquer l'API Applet obsolète dans le JDK 9, mais n'a pas l'intention de la supprimer de sitôt
