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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Alibaba publie en open source Dragonwell 8.0
Son JDK personnalisé pour les besoins spécifiques de l'entreprise

Le , par Bill Fassinou

744PARTAGES

4  0 
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 ?

Qu'en pensez-vous ?
Êtes-vous pour ou contre le fait que certaines entreprises créent leurs propres JDK ? Pourquoi ?
Quelles conséquences cela pourrait-il avoir sur le développement de l'OpenJDK ?

Voir aussi

James Gosling, le concepteur de Java, signe une pétition lancée contre Oracle pour son « manque d'engagement » à l'égard de Java EE

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

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

Java : une version à accès anticipé du JDK 13 est publiée, Oracle veut unifier les deux méthodes de la classe GraphicsEnvironment

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de matthius
Inactif https://www.developpez.com
Le 22/03/2019 à 7:48
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.
0  0 
Avatar de fab256
Membre confirmé https://www.developpez.com
Le 22/03/2019 à 10:06
Le backend FPC (Free Pascal) de la machine virtuelle Java (JVM) génère un byte code Java conforme aux spécifications du JDK 1.5 (et ultérieur) ainsi qu'à la machine virtuelle Dalvik de la plate-forme Android. Bien que toutes les fonctionnalités du langage FPC ne fonctionnent pas lorsqu'elles ciblent la machine virtuelle, la plupart le sont (ou le seront à l'avenir).
0  0 
Avatar de matthius
Inactif https://www.developpez.com
Le 22/03/2019 à 11:30
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.
0  0