1 pièce(s) jointe(s)
Alibaba publie en open source son Java Development Kit (JDK)
Alibaba publie en open source Dragonwell 8.0
son JDK personnalisé pour les besoins spécifiques de l’entreprise
Les ingénieurs d’Alibaba Group ont présenté récemment sur GitHub leur propre implémentation du JDK. Pour l’entreprise, cette implémentation est née de la nécessité pour elle de trouver une ressource Java bien adaptée à ses applications et permettre leur déploiement à grande échelle. « Lors de l'adoption d'OpenJDK pour exécuter nos applications, nous nous sommes rendu compte de la nécessité pour nous de le personnaliser spécifiquement pour les déploiements d'applications Java à grande échelle », a écrit l’équipe de travail. Cette personnalisation interne ou cette version en aval de l’OpenJDK d’Alibaba Group a été baptisée Alibaba Dragonwell 8.0. Comme on pouvait s’y attendre, cette personnalisation a été déployée pour les besoins spécifiques de l’entreprise. Alibaba Group étant en partie une entreprise du commerce électronique, les travaux d’implémentation de Dragonwell 8.0 se sont essentiellement concentrés sur cet aspect.
Dans la présentation de l’équipe de Dragonwell, il est souligné que ce dernier est optimisé pour les applications de commerce électronique, de finance et de logistique en ligne et fonctionne déjà sur plus de cent mille serveurs. « Alibaba Dragonwell est le moteur qui exécute nos applications Java distribuées avec une évolutivité extrême », a indiqué l’équipe. L’équipe d’Alibaba Dragonwell renseigne que ce dernier est certifié compatible avec le standard Java SE et la version actuelle ne prend en charge que la plateforme Linux pour les architectures x86 et x64. En plus d’être un fork de l’OpenJDK, il dispose d’autres caractéristiques que l’entreprise juge très essentielles pour leurs travaux.
Il dispose d’un nouveau Garbage Collector nommée CMS, d’un enregistreur de vol (JFR) et apporte de nouveaux ajouts dont voici quelques-uns :
- ajout d’une nouvelle option mini à la sous-commande dump de l’outil jmap pour ignorer le contenu des tableaux de type primitif de heapdump ;
- ajout d’une nouvelle option PrintYoungGenHistoAfterParNewGC pour imprimer l'histogramme d'objet après un GC ParNew ;
- ajout d’une nouvelle option PrintGCRootsTraceTime pour imprimer les détails du GC ParNew comme G1GC. Il aide les utilisateurs à trouver le problème du temps de pause long. Il peut être ouvert/fermé par jinfo ;
- ajout d’une nouvelle option ArrayAllocationWarningSize pour imprimer la pile d'appels d'une allocation de tableau dont la taille dépasse ArrayAllocationWarningSize. La valeur par défaut de cette option est 512M. Cela peut être changé par jinfo.
Pour certains au sein de la communauté Java, si beaucoup d’entreprises et d’organisations se lancent dans la construction de leurs propres JDK, c’est relativement pour éviter des problèmes avec Oracle qui détient des extensions propriétaires. Que ce soit Red Hat, Amazon et Azul, pour ne citer que ceux-là, ces entreprises ont tous leurs propres JDK. Selon elles, les extensions propriétaires d’Oracle détruisent la confiance des développeurs qui se détournent peu à peu du langage Java. Ont-ils raison de dire cela ? De plus, on se rappelle qu’en 2016, des partisans de Java EE soutenus par Red Hat et IBM décident de poursuivre leur propre développement de la plateforme indépendamment d’Oracle. Il s’agissait de certains développeurs qui avaient décidé de suivre leur propre voie en se réunissant au sein d’un groupe appelé Java EE Guardians, pour lancer une pétition adressée à la haute direction d’Oracle.
Ce groupe de partisans de Java EE avait également vu certains personnages et organisations rejoindre leur cause. Ce fut le cas notamment de James Gosling, le concepteur de Java. Se disant « préoccupés par le manque d’engagement d’Oracle vis-à-vis de Java EE », les Java EE Guardians s'étaient dits déterminés à faire tout ce qui est en leur pouvoir « pour préserver les intérêts de la communauté Java EE ». Ils avaient publié pour cela un plan d’action qui prévoyait de poursuivre dans une certaine mesure le développement de Java EE. Il s’agit notamment de travailler sur des fonctionnalités qui sont censées être dans Java EE 8. Le groupe de partisans de la plateforme avait mis en avant des fonctionnalités relatives à la sécurité, Java Message Service, et Jax-RS. Et ce, en travaillant en collaboration avec des fournisseurs tels que Red Hat, IBM, Tomitribe et Payara.
Par contre pour d’autres, Oracle ne dispose plus d’extensions propriétaires depuis le JDK 11 et maintenant le 12. Ils affirment également que les JDK de la plupart des entreprises précitées ou qui possèdent leurs propres JDK ont été développés par Oracle et les développeurs de ces entreprises travaillent tous ensemble pour contribuer à l’OpenJDK. « La confiance en Java et la coopération pour son développement ne font que grandir. Tout ceci en partie grâce au leadership d'Oracle et à la transparence de l'approvisionnement de l'ensemble de la plateforme », ont-ils souligné.
Source : GitHub
Et vous ?
:fleche: Qu'en pensez-vous ?
:fleche: Êtes-vous pour ou contre le fait que certaines entreprises créent leurs propres JDK ? Pourquoi ?
:fleche: Quelles conséquences cela pourrait-il avoir sur le développement de l'OpenJDK ?
Voir aussi
:fleche: James Gosling, le concepteur de Java, signe une pétition lancée contre Oracle pour son « manque d'engagement » à l'égard de Java EE
:fleche: JDK 11 : trois nouveautés sont prévues ainsi que la suppression de JAVA EE, JavaFX et CORBA, dans le cadre des mises à jour semestrielles
:fleche: Java : le JDK 12 est disponible en version bêta, il prend en charge Unicode 11 et dispose d'un nouveau format de clé privée codé x25519 et x448
:fleche: Java : une version à accès anticipé du JDK 13 est publiée, Oracle veut unifier les deux méthodes de la classe GraphicsEnvironment
Ce JDK est compatible avec Pascal
Si vous voulez anticiper le JAVA, sachez que les applications créées en Pascal peuvent être converties en byte-code JAVA.
Il n'y a pas que les JDK. Une vieille application Pascal peut toujours servir en devenant libre.
Particularité du byte-code Pascal
Le Byte-Code Pascal est nettement plus léger que le byte-code JAVA. En effet, les autres langages ont longtemps envié le remplacement de constantes par les énumérations. Il faut créer une classe en JAVA pour créer une énumération. En Pascal, on déclare directement l'énumération.
Ainsi les applications en Byte-Code JAVA peuvent être compatibles avec le Byte-Code Pascal, pas l'inverse.
