Discussion :

[Bruno]

Eclipse dévoile Adoptium, une place de marché pour les binaires Java, elle permettra aux développeurs d'accéder aux binaires standard,
d'Eclipse, Microsoft, IBM et d'autres fournisseurs

Eclipse, en collaboration avec son groupe de travail Adoptium, crée l'Adoptium Marketplace, qui fournira des binaires Java SE certifiés TCK (Technology Compatibility Kit) et Eclipse AQAvit (Adoptium Quality Assurance), tous basés sur OpenJDK. Alors que le TCK teste la compatibilité Java, l'AQAvit ajoute des tests de performance et d'évolutivité.

Java serait le premier langage de programmation et la première plateforme au monde. La place de marché Adoptium promeut des runtimes de haute qualité, certifiés TCK et vérifiés AQAvit, destinés à être utilisés dans l'ensemble de l'écosystème Java.

Les organisations qui prévoient de participer au marché Adoptium sont Eclipse, avec son runtime Temurin, Microsoft, avec la version Microsoft d'OpenJDK, IBM, avec son Runtime Semeru Certified Edition, Huawei, avec Bi Sheng, Alibaba Cloud, avec Dragonwell, Red Hat, avec sa version d'OpenJDK, et Azul, avec les versions Zulu d'OpenJDK.

La version Microsoft d'OpenJDK est désormais disponible, offrant une distribution gratuite de Java open source qui pourrait rivaliser avec les distributions Java d'Oracle pour conquérir le cœur et l'esprit des développeurs de logiciels d'entreprise.

Publiée le 25 mai après avoir été en phase de prévisualisation depuis avril, la Build Microsoft d'OpenJDK comprend des binaires pour Java 11, basés sur les environnements de serveur et de bureau OpenJDK 11.0.11+9 sur MacOS, Windows et Linux. Les versions OpenJDK 11 de Microsoft Build of OpenJDK sont des versions de support à long terme (LTS) et seront mises à jour trimestriellement.

« Aujourd'hui, nous sommes ravis d'annoncer la disponibilité générale de Microsoft Build d'OpenJDK, une nouvelle distribution gratuite d'OpenJDK qui est à code source ouvert et disponible gratuitement pour que chacun puisse la déployer partout », a écrit George Adams, Senior Program Manager chez Microsoft, dans un billet de blogue mardi. Il a rappelé que Java est fortement utilisé par Microsoft, avec plus de 500 000 JVM fonctionnant en interne. « Le Java Engineering Group est très fier de contribuer à l'écosystème Java et d'aider à alimenter des charges de travail telles que LinkedIn, Minecraft et Azure », a-t-il ajouté.

Les binaires de la version Microsoft Build of OpenJDK peuvent contenir des corrections et des améliorations ou des corrections et des améliorations rétroportées jugées importantes pour les clients et les utilisateurs internes mais qui n'ont pas été incorporées dans le projet OpenJDK en amont. Ces corrections et améliorations seront signalées dans les notes de publication avec le code source disponible.

« Nous avons déployé notre propre version d'OpenJDK sur des centaines de milliers de VM chez Microsoft et LinkedIn. Dans l'ensemble, Microsoft a plus de 500 000 machines virtuelles exécutant Java chez Microsoft », a renchéri Julia Liuson, vice-présidente de la division des développeurs de Microsoft. « Nous fournissons aussi ce service aux clients pour Azure », a-t-il ajouté. Microsoft publie en outre les images Docker OpenJDK et les Dockerfiles correspondants. Ces images pourront être utilisées par toute application Java ou tout composant d'application Java pour un déploiement n'importe où, y compris Microsoft Azure.

Avec la disponibilité générale, Microsoft publie également la Build Microsoft des images Docker d'OpenJDK et les fichiers Docker correspondants. Ceux-ci sont destinés à être utilisés par toute application Java ou composant d'application Java. Et la société publie un binaire Early Access de la version Microsoft Build d'OpenJDK pour Java 16 pour Linux et Windows sur ARM.

Oracle, l'intendant du développement continu du standard Java, le fournisseur de la principale distribution Java et un membre d'Eclipse, ne participe pas. « Oracle est absolument invité à se joindre à nous, mais jusqu'à présent, il a choisi de ne pas le faire », a déclaré Mike Milinkovich, directeur exécutif d'Eclipse. Une étude récente de la société de surveillance des applications New Relic a révélé que, si Oracle Java était toujours en tête, sa part avait glissé de 75 % du marché en 2020 à seulement 34,48 % cette année.

La solution d'entreprise Java Jakarta EE d'Eclipse ne sera pas disponible sur la place de marché Adoptium, mais Jakarta fonctionnera au sommet des implémentations Java trouvées sur la place de marché. Eclipse Adoptium et le groupe de travail Adoptium s'inscrivent dans la continuité de la mission originale AdoptOpenJDK établie en 2017 pour répondre à l'absence générale d'un système de construction et de test "ouvert", communautaire et reproductible pour OpenJDK sur plusieurs plateformes.

AdoptOpenJDK a ajouté 4 catégories de tests à ce jour (qui constituent des dizaines de milliers de tests, fonctionnant sur plusieurs plateformes, avec d'autres à venir au fur et à mesure de la disponibilité des machines) :

• tests de régression OpenJDK ("make openjdk") - depuis OpenJDK ;
• tests système (et stress) ("make system") - de AdoptOpenJDK/openjdk-systemtest ;
• tests d'applications tierces ("make external") - les tests unitaires provenant du dépôt github de chaque application, comme Scala, Derby, Cassandra ;
• tests de conformité (JCK) ("make jck") - sous licence OCTLA (OpenJDK Community TCK License Agreement).

Avec 2 autres catégories de tests en route :

• tests fonctionnels ("make functional") - à partir d'Eclipse/openj9 ;
• tests de performance ("make perf") - à partir de divers dépôts github open-source.

Pour faciliter l'exécution de ces tests, l’équipe a ajouté une enveloppe intentionnellement mince qui nous permet d'appeler des cibles make logiques pour exécuter ces tests. Ainsi, il est possible d’étiqueter et catégoriser le support de test de la manière suivante :

• groupe de test (comme énuméré ci-dessus, openjdk, système, externe, jck, fonctionnel, perf) ;
• version de Java (nous testons actuellement les versions Java8, Java9 et Java10) ;
• implémentation VM (nous testons actuellement OpenJDK avec Hotspot, et OpenJDK avec OpenJ9) ;
• niveau de test (par exemple, une vérification rapide pour les builds de pull request, nous pouvons marquer un sous-ensemble de tests de n'importe quel groupe avec "sanity", pour exécuter l'ensemble de sanity, "make sanity", pour exécuter juste le sous-ensemble de tests openjdk ou système qui ont été marqués alors "make sanity.openjdk" et "make sanity.system" respectivement).

« Nous sommes toujours en train de mettre en place et de faire fonctionner certaines de ces constructions de test. Et c'est là qu'intervient l'appel à l'aide... Nous serions ravis d'avoir des mains et des yeux supplémentaires sur les tests de AdoptOpenJDK », a déclaré Shelley Lambert, Vérification de logiciels chez AdoptOpenJDK / Eclipse OMR / Eclipse OpenJ9 et IBM Runtime Technologies.

« Nous savons que certains sont probablement dus à des irrégularités de configuration des tests ou des machines, tandis que d'autres sont des problèmes connus d'OpenJDK. Annoter correctement l'ensemble actuel d'échecs et réexécuter/réinclure les problèmes corrigés sont en tête de la liste des tâches à accomplir », poursuit-il.

Un grand pourcentage des JCK est automatisé. Il y a cependant un ensemble de ces tests de conformité qui sont manuels/interactifs. Nous recherchons quelques volontaires dévoués pour nous aider à effectuer les tests interactifs sur différentes plateformes. Ces tests ont été automatisés dans les builds Jenkins Pipeline, et l'équipe désire continuer à ajouter des builds pour les différentes plateformes sur lesquelles les binaires sont construits, des mains supplémentaires ici seraient également très utiles.

Source : Adoptuim

Et vous ?

Que pensez-vous de cette place de marché ?

Quel est votre avis sur la non-participation d'Oracle, le fournisseur de la principale distribution Java et membre d'Eclipse ?

Voir aussi :

Développeurs Java : la version d'OpenJDK de Microsoft est désormais disponible et inclut des binaires pour Java 11, basés sur OpenJDK 11.0.11

Les contrôleurs de conformité d'Oracle incluraient désormais Java dans les audits de licence, les abonnements payants introduits il y a trois ans retiennent désormais l'attention de l'équipe

[Mingolito]

C'est trop tard, Java est sur le déclin et de toute façon Kotlin c'est infiniment mieux que Java.

[Lor6s]

En réalité, l'initiative est intéressante. Je me suis souvent retrouvé à douter quant à la saveur de jdk/jre/crème vanille à choisir. Je n'apprécie pas particulièrement la société oracle dans sa gestion de l'écosystème java et une alternative est la bienvenue. Cependant, comment choisir ? J'ai tenté la mouture windows à ma grande déception et je ne vois pas forcément la différence entre OpenJDK et AdoptOpenJDK. J'ai pris cette dernière et je dois dire que je suis relativement satisfait.

Néanmoins, l'éclatement dans l'écosystème se fait de plus en plus sentir (coucou jigsaw) et on a vraiment l'impression que chaque major tente de tirer la couverture de son côté au dépend de la communauté... C'est dommage car, bien que le langage pourrait profiter de certaines améliorations (async/await est quand même un must), il reste à mon sens le meilleur sur le marché pour ce qui est non spécialisé.

Le libre/open source n'a pas forcément que des avantages... cf. La pléthore pantagruellique de distrib' Linux

[OButterlin]

C'est trop tard, Java est sur le déclin et de toute façon Kotlin c'est infiniment mieux que Java.

Ce genre d'affirmation n'engage que son auteur...
Si j'en crois le classement des langages 2022 de TIOBE, Java reste en 3ème position derrière Python et C.
Et à aucun moment on ne voit Kotlin... de là à parler d'un feu de paille pour adorateur de sucre syntaxique, il n'y a qu'un pas... que je franchis allègrement par pure provocation
Ceci dit, qu'il y ait des personnes qui préfèrent Kotlin à Java ne me dérange pas, libre à chacun de choisir son langage mais bon, il faut arrêter de dire que Java est mort, on se croirait dans les années 1980 quand on entendait : Cobol est mort (et il est toujours là).

Plus sérieusement, à regarder le classement, ça dépend beaucoup du type d'application. Je ne me vois pas développer une application web avec C, à l'inverse, je ne me vois pas non plus développer un driver en Java.
Python se maintient au top, dû peut-être à sa polyvalence.
Ce qui m'étonne le plus, c'est le résultat plutôt médiocre de javascript (et on ne voit même pas typescript dans le classement). On ne parle que des framework Javascript pour le web et là, bof...

Pour en revenir à l'article, Eclipse Adoptium me semble une bonne idée.
Qu'Oracle n'y participe pas (pour le moment en tout cas) m’indiffère.
Que Microsoft y participe me semble plutôt bien.