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 !

Java 9 : le comité exécutif du JCP rejette la spécification actuelle des modules Java (Jigsaw)
Qui a voté « Non » et pourquoi ?

Le , par Michael Guilloux

108PARTAGES

8  0 
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

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

Avatar de 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.
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 07/09/2017 à 17:24
Citation Envoyé par Matthieu Vergne Voir le message
Et c'est où qu'il prend en compte ce qui est faisable en interne ? Parce que bon, copier les autres a ses avantages, mais si c'est pour avoir en pratique le même rythme et se contenter de sortir des versions qui sont juste de moins en moins boguées, les utilisateurs resteront au rythme habituel pour éviter de perdre leur temps, en se contentant d'ignorer les versions intermédiaires.
L'intérêt c'est que les versions intermédiaires pourront proposer de nouvelles fonctionnalités plus "simple", sans avoir à dépendre du temps de développement trop important d'une autre fonctionnalités.

Par exemple si cela aurait été le cas on aurait déjà pu avoir le REPL, HttpClient avec support d'HTTP2, l'évolution de la classe Process, etc.

Citation Envoyé par Matthieu Vergne Voir le message
Ce qui veut dire qu'à terme il n'en restera qu'un seul. L'objectif, si on lit entre les lignes, et de supprimer l'un des deux. La question est alors de savoir lequel. Je vous le laisse en mille. Reste à voir ensuite l'évolution que ça engendrera, style pas en arrière sur les licences avec celui qui reste. En surface, ça semble génial, mais où sont les garanties ?
Moi je vois plutôt çà dans le sens où çà leur permettra de proposer plus facilement leur JDK commerciale.

S'ils tuent l'OpenJDK ils se prendront un gros bad-buzz, se retrouveront éjecté des distributions, et risqueraient de voir un fork...

Citation Envoyé par ParseCoder Voir le message
Dommage qu'Oracle n'ai pas choisit une license aussi libérale que la license du .NET Compiler Platform (Roslyn).
C'est à dire ?
On est sur du GPLv2 là je ne vois pas où est le problème...

a++
2  0 
Avatar de kilroyFR
Membre éprouvé https://www.developpez.com
Le 07/09/2017 à 20:38
Oracle ne faisant rien sans arriere pensée (il faut bien payer l'ile de l'insatiable ellison), du business, rien que du business dans cette strategie.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 11/09/2017 à 15:11
Citation Envoyé par Matthieu Vergne Voir le message
La position que je prend est plus celle du questionnement : qu'est-ce qui empêcherait Oracle de prendre de telles mesures aux dépends de la communauté ? À l'heure actuelle, je ne vois pas de garantie qui permette de se dire "ça c'est une bonne chose". J'ai l'impression qu'à l'heure actuelle, c'est plus une question de pari/confiance.
On peut toujours ce méfier, mais cette question n'a rien de particulier à la situation. On peut tout a fait la poser pour n'importe quel langage/société. Il n'y a pas plus de raison d'être sceptique qu'envers Microsoft, Google, Apple, Redhat, ...
2  0 
Avatar de 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...
1  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 10/05/2017 à 14:29
Je viens d'ailleurs de terminer de lire un chapitre à ce sujet :
Dunning, David. «*Prediction: The Inside View*». In Social psychology: handbook of basic principles, édité par Arie W. Kruglanski et E. Tory Higgins, 2nd ed., 69‑90. New York: Guilford Press, 2007.

En résumé : l'homme est une machine à prédire de la merde, mais ça se soigne.
1  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 04/06/2017 à 14:25
Bonjour,

Java9 semble s'approcher. J'utilise Karaf de longue date et après avoir relu le sujet, je pense que la notion de module de java9 et de module de OSGI sont suffisamment différentes pour ne pas être contradictoires.

J'ai vu que beaucoup de questions se posaient autour des deux notions de module.
De que j'ai conclus des mes essais avec le jdk9 et de mon expérience Karaf c'est que nous ne sommes pas du tout dans le même scope, bien qu'il y ait des usages qui se recouvre.

Je veux faire une application découpée en modules pour faciliter l'évolution la maintenance, etc. Mais que je lance comme un tout. Dans ce cas tant la notion de module de java9 que celle de OSGI peuvent faire l'affaire.

Je veux une application qui fonctionne comme un conteneur dans lequel je veux déployer des modules à la volée en arrêter les relancer les supprimer, etc. je veux qu'ils puissent interagir, se reconnaitre, etc. là le jdk9 ne le permet pas.

Pour moi l'apport de la modularité dans java9 permet essentiellement d'obtenir un runtime adapté au besoin de l'application. de définir des sous-ensembles réutilisables d'appli en appli. Alors que OSGI est plus un conteneur, et/ou un système de plug-in à chaud.

Je vais donc continuer à utiliser Karaf, aider à le faire fonctionner sur java 9. quant à l'usage que je fais du tout forcément se posera la question module java9 ou bundle OSGI. ce qui semble se dessiner c'est que les librairies de base vont probablement devenir des modules java9 alors que les composants de l'application resteront des bundles.

A+JYT
1  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 07/09/2017 à 14:47
Citation Envoyé par Michael Guilloux Voir le message
« En m’appuyant sur les modèles de publication utilisés par d'autres plateformes et par diverses distributions de système d'exploitation, je propose qu'après Java 9, nous adoptions un modèle strict et basé sur le temps avec une nouvelle version de fonctionnalités tous les six mois, des mises à jour chaque trimestre et une LTS tous les trois ans », peut-on lire dans son billet.
Et c'est où qu'il prend en compte ce qui est faisable en interne ? Parce que bon, copier les autres a ses avantages, mais si c'est pour avoir en pratique le même rythme et se contenter de sortir des versions qui sont juste de moins en moins boguées, les utilisateurs resteront au rythme habituel pour éviter de perdre leur temps, en se contentant d'ignorer les versions intermédiaires.

Citation Envoyé par Michael Guilloux Voir le message
L'objectif est de rendre l'OpenJDK et le JDK d'Oracle interchangeables. « Bien que nous sachions qu'il y aura d'abord des différences, notre intention est que, après quelques versions, il n'y ait plus de différences techniques entre les builds OpenJDK et les binaires Oracle JDK », a déclaré Smith.
Ce qui veut dire qu'à terme il n'en restera qu'un seul. L'objectif, si on lit entre les lignes, et de supprimer l'un des deux. La question est alors de savoir lequel. Je vous le laisse en mille. Reste à voir ensuite l'évolution que ça engendrera, style pas en arrière sur les licences avec celui qui reste. En surface, ça semble génial, mais où sont les garanties ?
2  1 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 07/09/2017 à 17:43
Citation Envoyé par adiGuba Voir le message
S'ils tuent l'OpenJDK ils se prendront un gros bad-buzz, se retrouveront éjecté des distributions, et risqueraient de voir un fork...
Fait converger les deux, après convergence tu justifies la suppression de l'un des deux avec les meilleurs arguments du monde : les deux sont équivalents, inutile de bosser deux fois, on est une structure solide et allons donc prendre en main le projet entièrement en embauchant les gens compétents qui travaillent sur l'autre. Cela passe donc notamment par l'acquisition des compétences clés de l'autre projet pour bosser sur le leur (pour rappel, on parle d'avoir OpenJDK en GPL, pas le JDK d'Oracle). De là, petite régression par petite régression, pour éviter que ça n'arrive trop vite, à coup de messages "oui mais comprenez, on fait de notre mieux mais c'est pas facile", le JDK officiel fini par perdre les attraits qu'on vend ici, et de là des voix recommencent à monter et à parler de forker le projet. Tu gères ça bien jusqu'à ce que la différence soit trop forte pour justifier la création d'un fork... sauf que trop tard, le JDK actuel n'est pas forkable, car c'est celui sous GPL qui a été arrêté il y a maintenant X années, et on doit donc repartir d'une version obsolète pour forker. Ajoute à cela que les experts du sujet sont désormais principalement chez Oracle et (potentiellement) contraint de par leur contrat de ne pas participer au projet concurrent, pour des raisons tout à fait normale de non concurrence, sous peine de licenciement, avec des poursuites judiciaires pour ceux qui n'auraient pas peur du licenciement.

Si tu t'organises pour tuer le projet à petit feu, d'ici à ce qu'un fork se recrée, tu auras déjà eu le temps de mettre à bas les forces vives concurrentes et d'établir une dépendance à ton propre JDK.

Évidemment, ce n'est que de la spéculation, qui plus est particulièrement pessimiste. Mais je ne vois pas ce qui l'empêcherai à l'heure actuelle.
2  1 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 07/09/2017 à 19:20
Oui mais s'ils comptent "tuer" OpenJDK ils peuvent le faire dès maintenant.
Pas besoin d'y ajouter des fonctionnalités...

L'intérêt au contraire c'est de déployer OpenJDK au maximum, et de pouvoir proposer leur offre commerciale derrière.
1  0