Discussion :

[Bill Fassinou]

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 ?

Que pensez-vous des nouvelles fonctionnalités de Java 17 ?

Voir aussi

Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK

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

Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres

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 ?

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

[grunt2000]

Humm, ils auraient pu aussi faire disparaître les modules...
Le flop absolu.

[Stéphane le calme]

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):

1. Restaurer une sémantique à virgule flottante toujours stricte (JEP 306)
2. Générateurs de nombres pseudo-aléatoires améliorés (JEP 356)
3. Nouveau pipeline de rendu macOS (JEP 382)
4. portage du JDK sur macOS/Aarch64 (JEP 391)
5. Dépréciation de l'API Applet pour suppression (JEP 398)
6. Encapsuler fortement les composants internes du JDK (JEP 403)
7. Pattern Matching pour switch (Preview, JEP 406)
8. Suppression de l'activation RMI (JEP 407)
9. Classes scellées (JEP 409)
10. Suppression du compilateur expérimental AOT et JIT (JEP 410)
11. Dépréciation du gestionnaire de sécurité pour la suppression (JEP 411)
12. API de fonction étrangère et de mémoire (incubateur, JEP 412)
13. API vectorielle (deuxième incubateur, JEP 414)
14. 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 Java :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
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
Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
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 ?
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

[Michael Guilloux]

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 ?

Ne pensez-vous pas qu'Oracle a rendu Java plus ouvert et maintenable avec les changements entamés depuis septembre 2017 ?
Y a-t-il aujourd'hui encore un intérêt à utiliser OpenJDK au lieu du JDK Oracle ?

Voir aussi

Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
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
Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
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 ?
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

[darklinux]

Oracle aurait dû le faire il y a longtemps , cela aurais de l’être un non-débat . Résultat Java n 'est plus crédible et Oracle non plus

[Pierre Louis Chevalier]

Oracle aurait dû le faire il y a longtemps

Ce problème a été résolu avec l'open JDK, la Oracle ne fait qu'acter une correction sur sa politique stupide, pour essayer de tenter de sauver son image qui devient de plus en plus déplorable.

Résultat Java n 'est plus crédible

Ça c'est faux, exemple : Emploi développeur 2020 : les langages les plus demandés et les mieux payés Java et JavaScript caracolent en tête

et Oracle non plus

Ca c'est possible :
Oracle annonce les résultats financiers du Q1 de l'exercice 2022 : ses actions chutent en raison d'un manque à gagner, malgré un chiffre d'affaires IaaS et SaaS s'élevant à 2,5 milliards de $
Oracle accusé d'avoir « braconné » des employés clés de CentralSquare Technologies pour détourner des secrets commerciaux, afin de développer l'une de ses activités
Une suppression de plus d'un millier d'emplois par Oracle serait actuellement en cours dans ses filiales en Europe

[damthemad]

ho la belle reculade.
Oracle a fait du mal à Java avec toutes ces décisions débiles et sa tentative pitoyable de racket.
Oracle est devenue une société voyou ; ils feraient mieux de créer des technologies que d'essayer d'étrangler leur clients.

[Bill Fassinou]

À 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) :

• JDK 11

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

• JDK 16

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

• JDK 17

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

• Première observation

Tableau 1 : Nombre de calculs de score par seconde avec G1GC sur les différents JDK

• Deuxième observation

Tableau 2 : Nombre de calculs de score par seconde avec ParallelGC sur les différents JDK

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

Tableau 3 : Nombre de calculs de score par seconde sur JDK 17 avec les différents ramasse-miettes

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 ?

Quel est votre avis sur le sujet ?
Que pensez-vous de cette comparaison entre le JDK 11, le JDK 16 et le JDK 17 ?

Voir aussi

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

Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK

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

Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres

La version définitive du JDK 13 est publiée avec la prise en charge d'Unicode 12.1 et de nombreuses améliorations

[sunzoo]

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

[walfrat]

Perso je vois une légende et aussi un caption pour chaque graphe.

Pour les tests qui ont été lancé, il s'agit sans doute de ceux là : https://github.com/kiegroup/optaplan...anner-examples

[Patrick Ruiz]

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 ?

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 ?
Quelles sont les raisons pour lesquelles le JDK d’Oracle demeure incontournable ?
Quels sont les ingrédients du JDK d’Oracle qui continuent à manquer à l’appel dans l’openJDK ?


Voir aussi :

Oracle annonce la disponibilité de Java 16 : tour d'horizon des nouvelles fonctionnalités et améliorations du JDK
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
Java 14 est disponible en version définitive avec de nouvelles fonctionnalités de productivité des développeurs, dont Switch Expressions, Records et autres
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 ?
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

[SuperPat]

"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."

Donc finalement, rien de nouveau, on peut toujours pas utiliser l'Oracle JDK en production gratuitement ? Pour moi c'est toujours aussi confus, car le post du blog d'Oracle indique :

"Oracle is making the industry leading Oracle JDK available for free, including all quarterly security updates. This includes commercial and production use."

[smarties]

C'est plus pratique OpenJDK, il est disponible dans les distributions Linux
Ensuite, vu ce qui s'est passé avec Google et Oracle (avec Android), il vaut mieux être prudent et ne plus utiliser les produits Oracle dis "gratuits"

[walfrat]

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.

En bref, soi tu vend ton application à l'entreprise qui donc la possède légalement et donc peux l'utiliser, quid de la maintenance assuré par le prestataire ?

Sinon si tu fourni un produit sous licence ce serait donc au fournisseur de l'application qui doit payer une licence Oracle puisque c'est lui qui possède l'application ?

"Oracle is making the industry leading Oracle JDK available for free, including all quarterly security updates. This includes commercial and production use."

Pire, ça fait de cette déclaration une déclaration mensongère.

[Ithildine]

Absence de visibilité à long terme... Chat échaudé...(vous connaissez la suite).

Si Oracle passait davantage de temps en R&D qu'en rédaction de licences obscures et ambigües pour, au final, ne jamais s'engager sur les points peu claires, savamment rédigés, et toujours laisser les gens sous le coup potentiel de licences à payer pour des sommes astronomiques, cela donnerait peut être, éventuellement, l'idée de considérer à nouveau d'utiliser leur JDK... et de mettre à la poubelle les heures de validations faites, contraints et forcés, pour continuer à livrer nos produits à nos clients...

En fait, non, je rigole, Oracle me paierait que je continuerai à fuir leurs produits et leurs licences comme la peste...

[professeur shadoko]

Par contre, il manque visiblement un référentiel de traduction quelque part.

sujet épineux s'il en est!
Dans les années 80 on avait essayé de mettre au point des traductions de termes techniques anglais qui soient à la fois parlants et pas ridicules...
Il n'est certes pas interdit d'employer ces termes anglais directement (on mange bien des bifsteack!) mais parfois .... on avait ainsi par exemple le terme "cheminom" pour un "Path" d'accès au fichier... mais l'usage ne s'est pas imposé.
Dans mes cours Java (et dans mes bouquins) j'ai quand même utilisé quelques termes en Français avec parfois des décalques comme "accesseur" , "mutateur" (qui me semblent quand même un peu mieux que "getter" et "setter") mais il reste des points difficiles (par ex. pour "Thread" ou pour "Pattern")... sans tomber dans des excès on peut parfois trouver des termes qui sont à la fois parlants et agréables... mais comment faire pour que leur usage se répande?
Bon je sors car tout ceci relève d'un autre sujet à mettre dans un autre fil de discussion.