Developpez.com

Une très vaste base de connaissances en informatique avec
plus de 100 FAQ et 10 000 réponses à vos questions

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

Le , par Stéphane le calme, Chroniqueur Actualités
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


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


 Poster une réponse

Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 22/05/2017 à 12:26
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+
Avatar de bouye bouye - Rédacteur/Modérateur https://www.developpez.com
le 30/05/2017 à 23:10
Mark Reinhold vient de proposer de repousser la date de sortie au 21 septembre

Citation Envoyé par http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html
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
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 31/05/2017 à 9:47
Java 9 sera encore repoussé à cause de la controverse autour de Jigsaw
Mark Reinhold demande un délai supplémentaire de huit semaines

Sans surprise, Java 9 ne pourra pas être livré le 27 juillet prochain, la date de disponibilité générale qui a été annoncée dans le dernier calendrier proposé par Mark Reinhold, architecte en chef du JDK chez Oracle. C’est la conséquence des objections initiées par Red Hat et IBM et qui ont eu le soutien d’autres membres du comité exécutif du Java Community Process (JCP).

Red Hat a mis en avant plusieurs problèmes, notamment le fait que de nombreux cas de déploiement d'applications largement implémentées aujourd'hui ne sont pas possibles sous le système de modules implémenté dans Java 9 (Jigsaw), ou nécessiteraient une réarchitecture significative. L'éditeur de distributions GNU/Linux s'inquiétait également de la fragmentation de la communauté Java. En raison de capacités d'interopérabilité insuffisantes et d'autres restrictions, Red Hat craint que Jigsaw crée deux mondes de développement de logiciels Java : le monde Jigsaw et celui des autres technologies de l'écosystème (chargeurs de classes Java SE, OSGi, modules JBoss, Java EE, etc.). Pour ces différentes raisons, entre autres, Red Hat a décidé de ne pas soutenir le JSR 376 (Jigsaw) lors du vote du comité exécutif du JCP. Ayant reconnu les problèmes évoqués par Red Hat, IBM a également décidé de voter « Non » et demandé que les membres du groupe d’experts en charge du JSR 376 trouvent un meilleur consensus sur la spécification.

Le 8 mai dernier, par un vote de 13 « Non » contre 10 « Oui », les membres du comité exécutif du JCP n’ont pas approuvé le passage de la spécification à la prochaine étape du processus. « Ce vote ne signifie pas que le JSR 376 est mort ni que Jigsaw a été rejeté », explique Mark Reinhold dans un message dans la liste de diffusion OpenJDK. « Cela signifie seulement que le comité exécutif a soulevé un certain nombre de problèmes qu'ils veulent que le groupe d'experts du JSR 376 corrige. Les règles JCP donnent au groupe d’experts trente jours, jusqu'au 7 juin, pour soumettre une spécification révisée pour un deuxième vote du comité exécutif qui se terminera au plus tard le 26 juin », a-t-il ajouté.

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 par le comité exécutif, d’après Mark Reinhold. Et il semble que des modifications sont en train d’être faites pour que ces préoccupations soient dissipées. Vu les contraintes de temps cependant, l’architecte en chef du JDK chez Oracle propose de repousser la sortie de Java 9, ce qui n’est pas surprenant. « Je suggère que dans le projet JDK 9, nous continuons à travailler vers l'objectif actuel consistant à produire une première build RC le 22 juin, mais ajustons la date de disponibilité générale afin de tenir compte du temps supplémentaire requis pour terminer le processus JCP. Pour être précis, je propose que nous déplacions la date de disponibilité générale de huit semaines, en passant du 27 juillet au 21 septembre », a-t-il suggéré.

La nouvelle proposition de Mark Reinhold a été soumise aux commentaires des committers du JDK 9. S’il n’y a aucune objection (ce qui devrait être le cas), ce sera le nouveau calendrier pour JDK 9.

Source : Mark Reinhold
Avatar de sekaijin 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
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 23/06/2017 à 16:11
Java 9 : Mark Reinhold d’Oracle prépare le chemin pour la première release candidate
seuls les bogues bloquants seront désormais corrigés

Comme nous le savons, Java 9 a été une fois de plus reportée suite à la désapprobation de la spécification du système de modules (JSR 376) par le comité exécutif du Java Community Process (JCP). Depuis lors, le groupe d’experts du JSR 376 a eu une série de discussions sur la manière de corriger les problèmes qui ont entraîné le rejet de la spécification. À la demande de Mark Reinhold d’Oracle, la date de disponibilité générale de Java 9 a été déplacée de huit semaines, afin de tenir compte du temps supplémentaire requis pour terminer le processus JCP. Elle passe désormais du 27 juillet au 21 septembre.

L’architecte en chef du JDK chez Oracle a toutefois demandé le maintien de l'objectif d’avoir une première build RC, en principe prévue pour le 22 juin ; ce qui a été accepté par les commiters. À l’approche de la première release candidate, Mark Reinhold a donc défini il y a quelques jours ses nouvelles priorités en ce qui concerne la correction des bogues. Il a proposé de resserrer les objectifs définis pour la phase Rampdown 2, en se concentrant sur les bogues qui sont vraiment bloquants. Il propose notamment de :

  • corriger tous les bogues P1 qui sont nouveaux dans le JDK 9 et critiques pour la réussite de cette version ;
  • différer explicitement les bogues P1 qui sont nouveaux dans le JDK 9, mais qui ne sont pas critiques pour cette version ou qui ne peuvent pas, pour une bonne raison, être corrigés dans cette version ;
  • et laisser la correction de tous les bogues P1 qui ne sont pas nouveaux dans le JDK 9 et qui ne sont pas critiques pour cette version, mais qui étaient auparavant ciblés pour le JDK 9.

La correction des bogues de priorité P2-P5 devrait également être reportée à des versions futures, que ce soit dans le code du produit, les tests ou la documentation. Mark Reinhold rappelle également aux personnes chargées de corriger les bogues qu'ils ne devraient pas changer la priorité d'un bogue afin de le retirer de la liste. La priorité devrait refléter l'importance de le corriger indépendamment d’une version particulière, comme cela a été une pratique courante pour le JDK depuis de nombreuses années.

Il faut aussi noter que les fonctionnalités ont été gelées depuis un bon moment, et aucune amélioration supplémentaire, quelle que soit la taille et le faible risque de la prendre en compte, ne sera approuvée après la build Release Candidate initiale. Si elle n’est pas déjà là, la première RC devrait être disponible dans les jours à venir.

Source : Open JDK mailing list

Et vous ?

Attendez-vous impatiemment Java 9 ou vous ne prévoyez pas de l'utiliser de si tôt ?
Avatar de Mimoza Mimoza - Membre habitué https://www.developpez.com
le 26/06/2017 à 10:35
Ça annonce rien de bon pour la qualité du la première version …
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 26/06/2017 à 21:45
les premières releases des versions majeures sont toujours difficiles.
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 27/06/2017 à 17:05
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 ?
Offres d'emploi IT
Expert Technico Fonctionnel Sharepoint H/F
Safran - Ile de France - Corbeil (91)
Ingénieur développement électronique H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Architecte / concepteur électronique numérique H/F
Safran - Ile de France - Éragny (95610)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil