IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

Oracle rétropédale en rendant son JDK 17 accessible sans coût pour une utilisation commerciale


Sujet :

Java

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    juin 2016
    Messages
    2 135
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 2 135
    Points : 46 053
    Points
    46 053
    Par défaut 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.

    Nom : java-17.png
Affichages : 127036
Taille : 5,8 Ko

    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
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre éclairé

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    592
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 592
    Points : 655
    Points
    655
    Par défaut
    Humm, ils auraient pu aussi faire disparaître les modules...
    Le flop absolu.

  3. #3
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    6 454
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 6 454
    Points : 155 272
    Points
    155 272
    Par défaut 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):
    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 { ... }

    Nom : java.png
Affichages : 38002
Taille : 8,4 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  4. #4
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    juillet 2013
    Messages
    2 492
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Data Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 492
    Points : 78 545
    Points
    78 545
    Billets dans le blog
    2
    Par défaut 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 ?

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  5. #5
    Membre extrêmement actif Avatar de darklinux
    Profil pro
    Consultant en technologies
    Inscrit en
    novembre 2005
    Messages
    539
    Détails du profil
    Informations personnelles :
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant en technologies
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2005
    Messages : 539
    Points : 875
    Points
    875
    Par défaut Un poil trop tard
    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

  6. #6
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    avril 2002
    Messages
    2 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : avril 2002
    Messages : 2 559
    Points : 17 125
    Points
    17 125
    Par défaut
    Citation Envoyé par darklinux Voir le message
    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.


    Citation Envoyé par darklinux Voir le message
    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



    Citation Envoyé par darklinux Voir le message
    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
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  7. #7
    Membre actif
    Homme Profil pro
    Consultant
    Inscrit en
    novembre 2013
    Messages
    22
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : novembre 2013
    Messages : 22
    Points : 227
    Points
    227
    Par défaut
    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.

  8. #8
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    juin 2016
    Messages
    2 135
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 2 135
    Points : 46 053
    Points
    46 053
    Par défaut À 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.

    Nom : java-17.png
Affichages : 154997
Taille : 5,8 Ko

    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



    Nom : comparison-java11-java16-java17-G1GC.png
Affichages : 7205
Taille : 17,8 Ko

    Nom : cs.png
Affichages : 7197
Taille : 27,8 Ko

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


    • Deuxième observation



    Nom : comparison-java11-java16-java17-ParallelGC.png
Affichages : 7190
Taille : 17,3 Ko

    Nom : sc.png
Affichages : 7201
Taille : 28,3 Ko

    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

    Nom : comparison-G1GC-ParallelGC-java17.png
Affichages : 7173
Taille : 15,3 Ko

    Nom : sq.png
Affichages : 7178
Taille : 20,4 Ko

    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
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  9. #9
    Membre du Club
    Profil pro
    Inscrit en
    janvier 2011
    Messages
    18
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2011
    Messages : 18
    Points : 45
    Points
    45
    Par défaut 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

  10. #10
    Membre expérimenté
    Profil pro
    Inscrit en
    juin 2009
    Messages
    502
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 502
    Points : 1 666
    Points
    1 666
    Par défaut
    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

  11. #11
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    février 2017
    Messages
    1 268
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 1 268
    Points : 38 332
    Points
    38 332
    Par défaut 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.

    Nom : 1.png
Affichages : 45625
Taille : 123,7 Ko

    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.

    Nom : 2.png
Affichages : 4794
Taille : 72,1 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  12. #12
    Membre du Club
    Profil pro
    Étudiant
    Inscrit en
    août 2004
    Messages
    79
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : août 2004
    Messages : 79
    Points : 55
    Points
    55
    Par défaut
    "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."

  13. #13
    Membre éprouvé
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    602
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2003
    Messages : 602
    Points : 1 288
    Points
    1 288
    Par défaut
    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"

  14. #14
    Membre expérimenté
    Profil pro
    Inscrit en
    juin 2009
    Messages
    502
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 502
    Points : 1 666
    Points
    1 666
    Par défaut
    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.

  15. #15
    Membre régulier
    Profil pro
    Développeur Java
    Inscrit en
    juillet 2008
    Messages
    42
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 42
    Points : 94
    Points
    94
    Par défaut
    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...

Discussions similaires

  1. Réponses: 21
    Dernier message: 18/10/2011, 08h37
  2. Réponses: 0
    Dernier message: 07/10/2011, 00h56
  3. Réponses: 0
    Dernier message: 12/10/2009, 10h31
  4. Réponses: 0
    Dernier message: 12/10/2009, 10h31
  5. choisir une version de java
    Par nadouz dans le forum Langage
    Réponses: 3
    Dernier message: 29/04/2006, 18h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo