Discussion :

[Aurelien.Regat-Barrel]

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?

[Mickael_Istria]

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.

[Aurelien.Regat-Barrel]

Merci pour les précisions. C'est très similaire au fonctionnement du comité de normalisation pour C++.

[Cafeinoman]

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?

[Mickael_Istria]

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.

[Michael Guilloux]

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

[Matthieu Vergne]

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.

[Matthieu Vergne]

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.

[Stéphane le calme]

JDK 9 : Mark Reinhold fait une proposition pour faciliter la migration vers la plateforme,
mais prévient qu'il s'agit d'une solution temporaire

Pour répondre aux craintes des développeurs qui s’inquiètent du fait que le code qui fonctionne sur JDK 8 aujourd’hui puisse ne pas fonctionner sur JDK 9 notamment à cause de la forte encapsulation des API internes de JDK, Mark Reinhold, l’architecte en chef de Java d’Oracle, a fait une proposition qui pourrait « aider l'ensemble de l'écosystème à migrer vers la plateforme Java modulaire à un rythme plus décontracté » : autoriser par défaut la réflexion illegal-access.

Pour rappel, la réflexion consiste à faire de l’introspection de classe, c’est-à-dire découvrir de façon dynamique des informations relatives à une classe ou à un objet en chargeant une classe, créant une instance et accédant aux membres statiques ou non sans connaître la classe par avance.

Qu’est ce que cela signifie concrètement ?

L’architecte en chef a expliqué que « big kill switch » existant de l’option permit-illegal-access va devenir le comportement par défaut du runtime JDK 9, mais sans autant d'avertissements.

Il a également ajouté que le comportement actuel de JDK 9, où les opérations réflectives illegal-access depuis le code sur le chemin de classe n'est pas autorisé, deviendra la valeur par défaut dans une version future et rien ne changera au moment de la compilation.

Reinhold a précisé qu’à terme, il est question de remplacer l’option --permit-illegal-access par une option plus généralisée ; le illegal-access. Ce dernier pourra prendre en paramètre un seul mot clé :

--illegal-access=permit

Ce sera le mode par défaut pour JDK 9. Il ouvre chaque paquet dans chaque module explicite à coder dans tous les modules non nommés, c'est-à-dire coder sur le chemin de la classe, tout comme l’autorise `--permit-illegal-access`. La première opération réflexive illegal-access provoque un avertissement, comme avec `--permit-illegal-access`, mais aucun avertissement ne sera émis après. Cet avertissement unique décrira comment activer d’autres avertissements.

--illegal-access=warn

Cela provoque un message d'avertissement pour chaque opération réflexive illegal-access. Cela équivaut à l'option actuelle `--permit-illegal-access`.

--illegal-access=debug

Cela provoque à la fois un message d'avertissement et une trace de pile pour chaque opération réflexive illegal-access. Cette option équivaut à combiner l'option `--permit-illegal-access` actuelle avec `-Dsun.reflect.debugModuleAccessChecks`.

--illegal-access=deny

Cela désactive toutes les opérations réflexives illegal-access, sauf pour celles qui sont activées par d'autres options de ligne de commande, telles que `--add-opens`. Cela deviendra le mode par défaut dans une version ultérieure.

Qu’en est-il des implications ?

Reinhold a prévenu que « le mode par défaut proposé permet au système d'exécution d'émettre un message d'avertissement, éventuellement longtemps après le démarrage, sans avoir été explicitement invité à le faire. Cela peut être une surprise dans les environnements de production, car il est extrêmement inhabituel pour le système d'exécution d'émettre des messages d'avertissement. Si le mode par défaut permet une réflexion illegal-access, il est donc essentiel de le faire savoir afin que les gens ne soient pas surpris lorsque cela ne sera plus le mode par défaut dans une version ultérieure ».

Il a ajouté que les messages d'avertissement dans n'importe quel mode peuvent être évités, comme cela était déjà le cas, par l'utilisation judicieuse des options `-add-exports` et` -add-opens`.

Si elle est adoptée, la proposition nécessitera des modifications au JEP 260 qui « Encapsule la plupart des API internes ». Bien que les API internes au JDK soient encore fortement encapsulées du point de vue du code dans les modules, que ces modules soient automatiques ou explicites, ils ne semblent pas être encapsulés au moment de l'exécution du point de vue du code sur le chemin de la classe.

En outre, lorsque "deny" va devenir le mode par défaut, Reinhold s'attend à ce que `permit` reste supporté pour au moins une version, afin que les développeurs puissent continuer à migrer leur code. Il convient de mentionner que les modes `allow`,` warn` et `debug` seront, au fil du temps, supprimés, et la même chose arrivera à l'option` -galgal-access`.

Probablement, la chose la plus importante à saisir est que, même si la proposition est adoptée et que la modification prend effet, elle ne « résoudra pas magiquement tous les problèmes d'adoption JDK 9. Les types concrets des chargeurs de classes intégrés sont encore différents,` rt .jar` est toujours parti, la mise en page d'une image système n'est toujours pas la même et la chaîne de la version possède encore un nouveau format ».

Source : Proposition Mark Reinhold

[Gugelhupf]

Salut,

Je fais parti de ceux qui sont impacté par cette migration car j'utilise la méthode setAccessible() dans mes API pour accéder aux champs qui ne sont pas public

A+

[bouye]

Mark Reinhold vient de proposer de repousser la date de sortie au 21 septembre

As you probably know by now, the JCP Executive Committee (EC) recently
voted [1] not to approve JSR 376, the Java Platform Module System [2],
for the next stage of the process.

This vote does not mean that JSR 376 is dead, nor that Jigsaw has been
rejected. It only means that the EC raised a number of concerns that it
wanted the JSR 376 Expert Group (EG) to address. The JCP rules give the
EG thirty days, until 7 June, to submit a revised specification for a
second EC vote, which will end no later than 26 June [3].

The JSR 376 EG held a series of conference calls over the past two weeks
in order discuss the EC's concerns [4]. The net impact of those meetings
on JDK 9 itself was to clarify the specification of the module system's
resolution algorithm, work on which had already begun, and to add one
five-line method to the module-system API. These changes, together with
additional clarifications to the JSR 376 and JSR 379 (Java SE 9) [5]
Specifications, will hopefully address the EC's concerns.

In order to be ready for all possible outcomes I suggest that here in the
JDK 9 Project we continue to work toward the current goal of producing an
initial Release Candidate build on 22 June [6], but adjust the GA date in
order to accommodate the additional time required to move through the JCP
process. To be specific, I propose that we move the GA date out by eight
weeks, from 27 July to 21 September.

Comments on this proposal from JDK 9 Committers are welcome, as are
reasoned objections. If no such objections are raised by 23:00 UTC next
Tuesday, 6 June, or if they're raised and satisfactorily answered, then
per the JEP 2.0 process proposal [7] this will be the new schedule for
JDK 9.

- Mark

[Mimoza]

Ça annonce rien de bon pour la qualité du la première version …

[sekaijin]

les premières releases des versions majeures sont toujours difficiles.

[Michael Guilloux]

Java 9 : le comité exécutif du JCP approuve la spécification révisée du système de modules Jigsaw
mais Red Hat s’abstient de voter

Le 8 mai dernier, 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 l’a prouvé : le comité exécutif du JCP a rejeté la spécification par un vote de 13 « Non » contre 10 « Oui ».

Des commentaires des différents votants, on a pu retenir 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 aussi l’interopérabilité ou la compatibilité avec des outils et systèmes populaires de l’écosystème Java. Le comité exécutif du JCP a donc accordé 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 » ont dit être prêts à soutenir la spécification révisée, si elle arrive à réconcilier les membres du groupe d’experts.

Depuis le vote du comité exécutif du JCP, le groupe d’experts du JSR 376 a eu une série de discussions sur la manière de corriger les problèmes évoqués et il semble que les modifications qui ont été faites ont permis de dissiper une bonne partie de ces préoccupations. Dans un nouveau vote du comité exécutif, la spécification révisée du système modules Java a en effet été approuvée presque à l’unanimité avec 24 des 25 membres ayant voté « Oui ». Red Hat a toutefois décidé de s’abstenir évoquant une satisfaction partielle.

« Red Hat s'abstient de voter en ce moment, car bien que nous pensons qu'il y a eu des progrès positifs au sein du groupe d'experts pour parvenir à un consensus depuis le dernier vote, nous croyons qu'il existe un certain nombre d'éléments dans la proposition actuelle, qui auront une incidence sur une adoption communautaire plus large, qui auraient pu être traités dans le délai de 30 jours pour cette version. Cependant, nous ne voulons pas retarder la sortie de Java 9 », explique Red Hat. L’éditeur de distributions Linux pense toutefois que les feedbacks sur le système de modularité seront « la clé pour comprendre si et où des changements doivent se produire. » Il espère donc que le responsable du projet et le groupe d’experts continueront à être aussi ouverts aux commentaires de la communauté Java plus large (utilisateurs et communautés au-delà de l’OpenJDK) qu'ils l'ont été au cours des 30 derniers jours de révision de la spécification.

IBM de son côté semble plus satisfait du travail qui a été fait ces derniers jours. Big Blue « approuve le passage de la spécification JPMS révisée […]. Comme décrit dans notre déclaration publique [mise en ligne en fin mai], IBM apprécie les nouvelles améliorations de compatibilité et de migration pour les applications d'entreprise qui ont ajoutées à la spécification », commente IBM.

En dehors de l’approbation de la spécification révisée du système de modules, la proposition de Mark Reinhold d’Oracle pour la phase Release Candidate de Java 9 a été validée, aucune objection n’ayant été faite. « Nous sommes maintenant dans la phase finale de la sortie [de Java 9] dans laquelle notre objectif sera de corriger uniquement les bogues vraiment bloquants pour la sortie de cette version », a-t-il annoncé. La build 175 du JDK 9 publiée le 22 juin devrait servir de point de départ pour préparer les releases candidates.

Sources : Vote du comité exécutif du JCP, Statut du JDK 9, Mark Reinhold (OpenJDK mailing list)

Et vous ?

Que pensez-vous du vote et de la décision de Red Hat ?
Êtes-vous optimiste au sujet de cette version de Java ?

[Namica]

En relisant une des sources de l'article : https://blogs.oracle.com/java-platfo...ion-of-java-se
J'ai vraiment difficile de faire la part des choses entre les craintes de Matthieu Vergne et l'opinion de adiGuba.
L'article me parait aller dans le bon sens et l'avis de Matthieu Vergne ne relève-t-il pas de la paranoïa ?
J'aurais tendance à suivre l'avis de adiGuba, mais ...
Mais voilà, peut on réellement avoir confiance dans Oracle et ses licences et discours plus que tortueux ?
Matthieu Vergne a peut-être un nez plus fin que le mien ou celui d'adiGuba.
(ou, nous sommes peut-être plus naïf que lui ?)
Qu'en pensez-vous ?

Voir aussi:

• /!\ https://www.droit-technologie.org/ac...le-netes-seul/
• https://www.droit-technologie.org/ac...ar-la-justice/
• http://www.avocats-picovschi.com/le-...ticle_882.html

[Matthieu Vergne]

La paranoïa, non. Je ne fait qu'énoncer une possibilité, et non une conviction. J'ai déjà affirmé que ce n'était que de la spéculation.

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.

[Namica]

La paranoïa, non. Je ne fait qu'énoncer une possibilité, et non une conviction. J'ai déjà affirmé que ce n'était que de la spéculation.

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.

J'avais bien compris ta position: "qu'est-ce qui empêcherait Oracle de prendre de telles mesures aux dépends de la communauté ?", malgré les annonces en référence.

[Matthieu Vergne]

Étant occupé depuis quelques semaines, et ne suivant pas de près ce sujet, je n'ai pas lu ces références. Je me suis concentré sur ce que rapporte l'article.

[Uther]

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, ...

[Matthieu Vergne]

Ce qui ne justifie pas de ne pas se la poser. Ce n'est pas parce qu'on se pose la même question que la réponse est forcément la même, fut-elle indécidable. Il s'agit de considérer les informations disponibles, qui elles dépendent du contexte.