Modules Java : Mark Reinhold d'Oracle remet en cause la bonne foi de Red Hat et IBM
Et invite le comité exécutif du JCP à soutenir le projet Jigsaw

Le , par Michael Guilloux, Chroniqueur Actualités
Red Hat et IBM ont récemment annoncé qu’ils n’apporteront pas leur soutien au système de modules implémenté dans Java 9, dans sa forme actuelle. Ils estiment que le JSR 376 (Java Platform Module System) n'est pas prêt en ce moment pour dépasser l'étape de la révision publique et qu’un délai supplémentaire vaut le coût pour résoudre les problèmes évoqués. En ce qui concerne ces problèmes, on peut les résumer comme suit : le système de modules introduits dans Java 9 apporte une solution qui ne couvre pas tous les cas d'utilisation, mais vient également avec des capacités d'interopérabilité insuffisantes et d'autres restrictions, qui pourraient créer une fragmentation de la communauté Java.

Le problème est qu’il existe d’autres implémentations de modules dans Java, dont les principales sont les modules JBoss de Red Hat, et OSGi qui est pris en charge par un certain nombre de fournisseurs, y compris IBM. Ainsi, les objections de Red Hat et IBM sont-elles de bonne foi ou visent-elles simplement à défendre leurs intérêts personnels ? Pour Mark Reinhold d’Oracle, ces entreprises cherchent simplement à défendre leurs intérêts. L’architecte en chef du JDK chez Oracle a donc sévèrement critiqué les deux fournisseurs, dans une lettre ouverte publiée hier, avant d’inviter les membres du comité exécutif du Java Community Process (JCP) à soutenir le JSR 376.

Mark Reinhold rappelle avant tout que l'objectif de ce JSR (soumis et approuvé par le comité exécutif en décembre 2014) est de concevoir un système de module accessible à tous les développeurs pour leur utilisation dans leur propre code, mais évolutif vers la modularisation de la plateforme Java SE elle-même. Et la spécification actuelle a atteint cet objectif.

Mark Reinhold affirme que Red Hat « a d'abord accepté les objectifs et les exigences du JSR, mais a travaillé de façon constante à les saper. Ils ont tenté de transformer ce JSR en autre chose que ce qui était prévu. Plutôt que de concevoir un système de module à la fois accessible et évolutif, ils ont plutôt voulu concevoir un "méta" système de modules par lequel plusieurs systèmes de modules différents pourraient interagir profondément ». Et de déduire : « Je ne peux supposer qu'ils ont poursuivi cet objectif alternatif afin de préserver et de protéger leur système de modules non standardisé, qui est peu utilisé en dehors de l'écosystème JBoss/Wildfly », dit-il. « La conception d'un "méta" système de modules serait un projet intéressant », poursuit Mark Reinhold, « mais ce serait encore plus large et beaucoup plus difficile que ce JSR. En se concentrant sur un public d'experts de système de modules, cela entraînerait probablement une conception qui n'est pas accessible à tous les développeurs. C'est pourquoi j'ai souligné à maintes reprises à Red Hat Middleware que beaucoup des fonctionnalités qu'ils préconisaient étaient hors de portée, mais ils ont choisi de ne pas accepter ces décisions. »

La décision de Red Hat de ne pas soutenir le système de modules introduit dans Java 9 n’est donc pas une surprise pour Mark Reinhold. Par contre, le « non » d’IBM était vraiment inattendu. « IBM a dit très peu de choses au cours de ce JSR. Après avoir annoncé qu'ils voteraient contre, ils ont ensuite envoyé une liste de problèmes spécifiques au groupe d’experts (EG), mais seulement en réponse à une demande d'un autre membre de l’EG. Aucun de ces problèmes n'est nouveau, beaucoup d'entre eux ont été discutés depuis longtemps, et IBM était silencieux pendant la plupart des discussions », affirme Mark Reinhold. « La position récente d'IBM semble être figée sur un désir vague d’un meilleur consensus parmi les membres de l’EG. Je préférerais davantage de consensus, mais ce n'est pas possible compte tenu de la position de Red Hat Middleware. Je ne peux donc conclure que IBM a décidé que ses intérêts sont mieux servis en retardant ce JSR et aussi le JSR 379 (Java SE 9), ce qui est regrettable ».

Mark Reinhold reconnaît que la spécification actuelle de ce JSR n'est pas parfaite, mais reflète des années de développement, de test et d'amélioration avec des feedbacks actifs de nombreux développeurs. Il est d'accord avec le fait que la spécification pourrait être améliorée s'ils y passent plus de temps. Il estime également que « ce que nous avons maintenant ne résout pas tous les problèmes pratiques liés à la modularité auxquels sont confrontés les développeurs, mais ils répondent aux objectifs et aux exigences convenus et constituent une base solide pour les travaux futurs. Il est temps de livrer ce que nous avons, de voir ce que nous en tirons comme leçon et d'améliorer itérativement », dit-il, avant d’ajouter de ne pas laisser la recherche du parfait empêcher de livrer ce qui est déjà bien : « Ne laissez pas le parfait être l'ennemi du bon ».

Pour conclure, Mark Reinhold réaffirme qu’on ne devrait pas retarder ce JSR (peut-être pendant des années) afin d'obtenir un meilleur consensus, sachant que certains poursuivent un objectif différent ; lequel objectif pourrait aboutir à une plateforme bloatware et complexe qu'aucun développeur n’utiliserait, ce qui n’est pas dans le meilleur intérêt de la communauté Java. Il rappelle également que le JCP « ne prévoit pas de consensus et pour une bonne raison. Il donne délibérément des pouvoirs de décision aux Specification Leads, précisément pour empêcher les membres de l'EG d'obstruer les progrès afin de défendre leurs propres intérêts. » Il appelle les membres du comité exécutif qui se demandent ce que sera leur vote, de juger la spécification sur le fond et non de voter contre le JSR en raison du manque de consensus dans l'EG. Un tel vote sera « un vote contre le JCP lui-même », dit-il, et condamne les futurs JSR « au consensus des "experts" qui se servent ».

Source : Lettre ouverte de Mark Reinhold

Et vous ?

Que pensez-vous des déclarations de Mark Reinhold ?
Red Hat et IBM essaieraient-ils de protéger leurs intérêts au détriment de celui de la communauté ?
Faut-il livrer ce qu’on a déjà ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de steel-finger steel-finger - Membre habitué https://www.developpez.com
le 06/05/2017 à 11:42
Quelqu'un sais comment va fonctionné ce système de module ?

Sinon ça ne m'étonne pas de RedHat & IBM, ils protègent leur intérêts et c'est normal n'importe quelle entreprise ferais de même
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 06/05/2017 à 12:55
C'est pour gérer / arbitrer ce genre de situation que les processus de standardisation existent.

En C++, il y a en ce moment un peu le même souci : créer un système de modules avec la difficulté de gérer la transition / compatibilité avec l'existant. Microsoft et Google développent chacun leur vision et se sont un peu frittés sur le sujet. Mais le processus ISO protège mieux il me semble contre les intérêts propres à ces groupes car au final leur vote est noyé dans la masse.

Quelqu'un sait comment ça se passe avec Java? Combien de personnes / acteurs ont le droit de voter?
Avatar de Mickael_Istria Mickael_Istria - Membre émérite https://www.developpez.com
le 06/05/2017 à 13:04
Citation Envoyé par steel-finger Voir le message
Sinon ça ne m'étonne pas de RedHat & IBM, ils protègent leur intérêts et c'est normal n'importe quelle entreprise ferais de même
Les inquietudes sont purement techniques et en rien politiques, et les problemes mentionnes sont valables pour tout l'ecosysteme Java. Il ne faut pas voir la critique d'une specification comme un moyen de ralentir le monde, disons qu'il faut plutot le voir comme un coup de frein pour etre sur de ne pas louper le virage...
Avatar de Mickael_Istria Mickael_Istria - Membre émérite https://www.developpez.com
le 06/05/2017 à 13:10
Citation Envoyé par Aurelien.Regat-Barrel Voir le message
Quelqu'un sait comment ça se passe avec Java? Combien de personnes / acteurs ont le droit de voter?
Les changement de specification de Java (nommes JSR) passent par un systeme de standardisation, avec revue, vote et compagnie - nomme JCP. Chaque spec definit des "expert groups" qui contribuent et ont le droit de vote. Pour JPMS, c'est https://www.jcp.org/en/jsr/detail?id=376 . Les specifications peuvent etre un peu "adoptees" avant la revue et compagnie, mais tant qu'il n'y a pas approbation de tous, ca reste externe a la spec Java; souvent le process se fait dans l'autre sens: ca part d'une solution existant (genre Spring) pour en extraire les parties interessantes a ajouter du contenu dans la spec Java/JavaEE et ca se passe bien. La on est sur un truc tres structurant et qui ne reprend pas specialement les solutions actuelles qui marchent, et qui semble avoir encore des defauts majeurs, c'est pour ca que ca coince un peu.
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 06/05/2017 à 16:54
Merci pour les précisions. C'est très similaire au fonctionnement du comité de normalisation pour C++.
Avatar de Cafeinoman Cafeinoman - Membre éprouvé https://www.developpez.com
le 06/05/2017 à 17:36
Citation Envoyé par Mickael_Istria Voir le message
La on est sur un truc tres structurant et qui ne reprend pas specialement les solutions actuelles qui marchent, et qui semble avoir encore des defauts majeurs, c'est pour ca que ca coince un peu.
J'ai deux questions : d'abord, pourquoi ne pas être partie justement de "truc qui marche", genre maven ou osgi? Deuxièmement, tu peux expliciter les défauts majeurs, vu qu'à priori tu suis plutôt de près ? Il est dit plus haut que ca coince côté Maven notamment, mais à quel point?
Avatar de Mickael_Istria Mickael_Istria - Membre émérite https://www.developpez.com
le 09/05/2017 à 9:22
Citation Envoyé par Cafeinoman Voir le message
J'ai deux questions : d'abord, pourquoi ne pas être partie justement de "truc qui marche", genre maven ou osgi? Deuxièmement, tu peux expliciter les défauts majeurs, vu qu'à priori tu suis plutôt de près ? Il est dit plus haut que ca coince côté Maven notamment, mais à quel point?
J'avoue que sur la premiere question, je ne connais pas la reponse.
Pour Maven, je te suggere de lire la derniere proposition pour JPMS (qui est dans l'un des derniers liens postes), qui re-explique un peu le probleme et propose une solution satisfaisante mieux que je ne saurais le faire.
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 09/05/2017 à 16:34
Java 9 : le comité exécutif du JCP rejette la spécification actuelle des modules Java (Jigsaw)
qui a voté « Non » et pourquoi ?

Comme prévu, le 8 mai, les membres du comité exécutif du Java Community Process (JCP) ont voté sur le système de modules Java (Jigsaw). Bien avant le vote, IBM et Red Hat avaient exprimé des préoccupations au sujet du système de modules Java (Java Platform Module System, en abrégé JPMS), et annoncé qu’ils allaient voter « Non ». Ils n’étaient toutefois pas les seuls parmi les membres du comité exécutif du JCP à désapprouver le JSR 376 (Java Platform Module System) et le vote d’hier vient de le prouver. Le comité exécutif du JCP vient en effet de voter avec 13 « Non » contre 10 « Oui ». Qui a voté contre le JSR 376 et pour quelles raisons ?


Avant d’aller plus loin, il est important de rappeler les conditions qu’il fallait remplir pour que le JSR soit approuvé. Le JSR est approuvé si (a) au moins une majorité des deux tiers des votes exprimés sont des votes « Oui », (b) un minimum de 5 votes « Oui » sont exprimés, et (c) Oracle vote également « Oui ». Autrement, il sera rejeté.

Comme vous pouvez le voir, la première condition déjà n’a pas été remplie, étant donné que les « Non » enregistrent plus de la moitié des votes ; ce qui indique un clair rejet des modules Java (version Jigsaw). Des commentaires des différents votants, on retient deux raisons principales à cette objection : la nécessité d’un consensus entre les membres du groupe d’experts travaillant sur le système de modules, mais surtout l’interopérabilité ou la compatibilité avec des outils et systèmes populaires de l’écosystème Java.

La nécessité d’un meilleur consensus entre les membres du groupe d’experts du JSR 376 est une raison évoquée par certains membres du comité exécutif ayant voté « Non ». D’après le fournisseur Hazelcast par exemple, « le manque de consensus au sein du groupe d'experts est un signe dangereux qui indique que tous les problèmes n'ont pas été clarifiés comme ils le devraient ou que certains problèmes ont été marqués résolus d'un seul point de vue. » Il est rejoint par Software AG qui lui aussi « s'inquiète de l'absence d'un consensus parmi les membres du groupe d'experts. » Bien que Software AG reconnaisse qu’un consensus parfait soit impossible, la société pense qu’un meilleur consensus reste quand même possible, et que cela « entraînerait un écosystème Java plus sain et une transition plus douce de l'industrie vers un monde Java modulaire. » Ils ne sont toutefois pas les seuls à demander un meilleur consensus. Tomitribe, Twitter, London Java Community et Crédit Suisse sont également de cet avis.

Mais dans le fond, c’est l’interopérabilité et la compatibilité avec les outils et systèmes populaires de l’écosystème Java qui sont à l’origine du rejet de la spécification des modules Java dans sa forme actuelle. C’est ce que résume Werner Keil, architecte logiciel et membre du comité exécutif du JCP depuis 2008. « Je comprends les raisons d'IBM et d'autres pour leur vote "Non" et j'ai entendu de nombreuses préoccupations similaires, par exemple, de la communauté OSGi ou de contributeurs derrière les grands systèmes de build comme Maven, Gradle ou Ant. La plupart de leurs préoccupations ne sont pas encore résolues », dit-il. Software AG, pour sa part, réclame également « une attention particulière » sur la question de « la migration des logiciels existants vers le monde modulaire et à la coexistence de la spécification avec les pratiques Java et les systèmes de build existants. »

Avec ce vote, le JCP accorde un délai de 30 jours au Specification Lead, Mark Reinhold d’Oracle, pour tenter de trouver un consensus au sein du groupe d’experts, donc probablement régler les problèmes évoqués et soumettre une nouvelle proposition. Il faut également préciser que certains membres qui ont voté « Non » disent être prêts à soutenir la spécification, si les membres du groupe d’experts trouvent un meilleur consensus. Mais vu les déclarations publiques de Red Hat et IBM, et celles d’Oracle, on peut se demander si ces 30 jours seront suffisants pour trouver un compromis. Cela dit, Java 9 sera-t-il encore repoussé ? Et combien de temps faudra-t-il encore attendre avant sa livraison ?

Source : Vote du comité exécutif du JCP

Et vous ?

Que pensez-vous du vote ?

Voir aussi :

Java 9 : une nouvelle proposition d'Oracle pour résoudre l'un des problèmes évoqués par Red Hat sur le système de modules Java (Jigsaw)
Modules Java : Mark Reinhold d'Oracle remet en cause la bonne foi de Red Hat et IBM et invite le comité exécutif du JCP à soutenir le projet Jigsaw
Java 9 : IBM et Red Hat vont voter contre l'implémentation des modules Java via Jigsaw, une solution qui ne couvre pas tous les cas d'utilisation
Avatar de bouye bouye - Rédacteur/Modérateur https://www.developpez.com
le 09/05/2017 à 23:10
Erf, a deux mois de la sortie planifiée et déjà repoussée de nombreuses fois, c'est limite ridicule...
Avatar de Matthieu Vergne Matthieu Vergne - Expert éminent https://www.developpez.com
le 10/05/2017 à 7:27
La prédiction n'a jamais été une science exacte, d'une part, et d'autre part la manie d'établir des dates de rendu même quand on n'en sait fichtrement rien n'aide pas à ce qu'elles soient respectées. Dans ces conditions, on a beau faire ce qu'on peut, il ne faut pas s'étonner que ça arrive.
Contacter le responsable de la rubrique Accueil