Discussion :

[Vyrob]

Y a un truc qui m'échappe : pourquoi se manifestent-ils seulement maintenant, à 3 mois de la release ? Le projet Jigsaw ne date pourtant pas d'hier.

[Padget]

C'est vrai qu'à trois mois d'une release... c'est un peu court pour rebondir. Mais bon, si cela aboutis, cela sera une excellente amélioration pour Java. Le principal avantage sera la taille en mémoire de la JVM qui va considérablement baisser. On rejoint aussi le crédo du C++ : ne t'embarrasse que ce dont tu as la nécessité.
Par contre si, comme certains semblent le supposer, Oracle se détourne de Java, il risque (tant mieux ?) d'y avoir une reconversion de pas mal de développeur vers d'autres écosystèmes (.Net par exemple) : "Le malheur des uns, fait le bonheur des autres".

[Mickael_Istria]

Y a un truc qui m'échappe : pourquoi se manifestent-ils seulement maintenant, à 3 mois de la release ? Le projet Jigsaw ne date pourtant pas d'hier.

Il faut lire les posts detailles et les discussions en lien.
Les inquietudes vis-a-vis de Jigsaw et de son interet technique et pour la communaute ont ete manifestees par tous des le debut. La compatibilite avec OSGi ou Maven a ete identifiee comme critique tres tot. Maitenant que Jigsaw a atteint un "pallier", il a ete teste dans ces environnements (OSGi et Maven) et il apparait qu'en l'etat actuel, ca complique tout sans ajouter grand chose. En l'etat actuel, il ne delivre pas les promesses qui ont ete identifiees initialement comme des "requirements".
Si l'annonce n'est publiee que maintenant, c'est qu'avant, il y avait encore de l'espoir que ca tourne mieux; mais maintenant, Jigsaw est face a un constat d'echec programme, et il est donc temps d'etre plus explicite si on veut que les choses aillent dans le bon sens.

Le principal avantage sera la taille en mémoire de la JVM qui va considérablement baisser.

Si par memoire tu entends "espace disque du deliverable", OK. Pour la RAM ou le Heap ca ne devrait pas changer grand chose car les classloaders ne chargent deja que ce qui est utile.

[Cafeinoman]

C'est sûr que si au final, ca fait un peu d'OSGI et un peu de Maven, mais en moins bien, tout en ne marchant pas ni avec l'un ni avec l'autre, ça n'a pas d'intérêt...

[Vyrob]

Il faut lire les posts detailles et les discussions en lien.

Je n'ai lu que cette news effectivement, je n'ai pas été voir les articles qui y sont liés. C'est juste que je pensais qu'avec leur processus de développement, ils se seraient rendu compte dès le début si ça n'allait pas, et de fait n'auraient pas eu besoin d'attendre d'en être à la dernière phase pour manifester leur refus. M'enfin il semblerait que je me sois trompé ! Merci pour l'explication en tout cas.

[Michael Guilloux]

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)

Comme nous l’avons rapporté récemment, Red Hat et IBM ont décidé de voter contre le projet Jigsaw qui vise à fournir un système de modules standardisé à la plateforme Java. Dans un billet de blog, un ingénieur de Red Hat a exposé les raisons de cette position. Il explique que de nombreux cas de déploiement d'applications largement implémentées aujourd'hui ne sont pas possibles sous Jigsaw, ou nécessiteraient une réarchitecture significative. Il pense également que l’écosystème Java sera perturbé, expliquant que dans certains cas, Jigsaw contredit des années de meilleures pratiques de déploiement d'applications modulaires qui sont déjà couramment utilisées par l'écosystème dans son ensemble. L’un des points également mis en avant par l’ingénieur de Red Hat est la fragmentation de l’écosystème. En raison de capacités d'interopérabilité insuffisantes et d'autres restrictions, il craint qu'il y ait deux mondes de développement de logiciels Java : le monde Jigsaw et le monde « tout le reste » (chargeurs de classes Java SE, OSGi, modules JBoss, Java EE, etc.).

Dans les détails, Red Hat explique encore que les modules automatiques de Jigsaw ne sont pas bien accueillis par la communauté ; un problème qu’Oracle veut résoudre avec une nouvelle proposition. Pour information, les modules automatiques sont considérés comme un mécanisme de compatibilité qui permet de « transformer » les JAR en modules dans un environnement modulaire. L'idée est qu'un module soit généré automatiquement à partir d'un JAR ; le nom du module serait alors un nom dérivé de celui du JAR, après diverses transformations pour le faire s'aligner sur la convention de nommage proposée pour les modules. Le problème est que de nombreux membres de la communauté estiment que les modules automatiques risquent d'apporter plus de mal que de bien, notamment à cause des risques de collision de noms.

Ils ont donc suggéré à Mark Reinhold d'Oracle, Specification Lead du projet Jigsaw, de « réviser l'algorithme qui calcule les noms des modules automatiques pour inclure l'identifiant de groupe Maven, lorsqu'il est disponible dans le fichier 'pom.properties' d'un fichier JAR ». Cela devrait faire « en sorte que les noms des modules soient moins susceptibles d'entrer en collision. » Dans le cas contraire, Mark Reinhold devrait envisager de « supprimer entièrement la fonctionnalité des modules automatiques », étant donné qu’elle peut créer plus de problèmes qu’en résoudre.

Mark Reinhold a donc fait des ajustements à son plan sur les modules Java, mais propose de ne pas supprimer la fonctionnalité de modules automatiques. D’après l’architecte en chef de la plateforme Java chez Oracle, la fonctionnalité de modules automatiques est « une partie critique de toute l’histoire de migration : elle permet aux développeurs d'applications de commencer à modulariser leur propre code sans avoir à attendre que toutes les bibliothèques et les frameworks qu'ils utilisent soient modularisés », dit-il. « Les bibliothèques et les frameworks populaires qui sont activement maintenus seront éventuellement modularisés assez rapidement, mais les projets moins actifs prendront plus de temps – peut-être des années ou même des décennies – et de nombreux projets inactifs ou abandonnés ne seront jamais modularisés. » C’est en cela que les modules automatiques sont importants dans le projet Jigsaw.

Mark Reinhold ne compte toutefois pas non plus réviser l'algorithme qui calcule les noms des modules automatiques, comme cela lui a été suggéré. « La suggestion d'utiliser les coordonnées Maven lorsqu'elles sont disponibles aiderait moins de la moitié des projets les plus populaires en cours d'utilisation aujourd'hui, d'après trois enquêtes différentes », dit-il. Par contre, il propose de ramener l’attribut manifeste de fichier JAR, une option qui avait été suggérée précédemment, mais qu’il avait rejetée. « L'attribut manifeste 'Automatic-Module-Name' est, d'un point de vue technique, esthétiquement désagréable, car il définit une deuxième façon de nommer des modules. Pris seul, cependant, il permet une modularisation non coordonnée en utilisant des noms de modules stables avec peu d'effort, et donc il semble que ce soit la moins mauvaise option sur la table », a-t-il expliqué. Il recommande par ailleurs que tous les modules soient nommés selon la convention de nom de domaine Internet inversé.

La nouvelle proposition de Mark Reinhold ne résout pas complètement le problème, mais semble déjà satisfaire un bon nombre de personnes, y compris les développeurs du projet Apache Maven. « Je pense que c'est un développement formidable qui permettra d’emprunter le chemin vers la modularisation et s’éloigner de la fragmentation potentielle de l'écosystème Java », a répondu Brian Fox, ancien président du projet Apache Maven.

Il est important de noter que la proposition d'Oracle ne vient pas en réponse aux inquiétudes exprimées par Red Hat et IBM. Il s'agit en effet d'un problème sur lequel une discussion a été ouverte il y a des mois déjà.

Sources : Proposition révisée de Mark Reinhold, Réponse de Brian Fox

[Michael Guilloux]

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

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à ?

[steel-finger]

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

[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]

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

[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

[bouye]

Erf, a deux mois de la sortie planifiée et déjà repoussée de nombreuses fois, c'est limite ridicule...

[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+