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 !

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

94PARTAGES

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

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

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 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 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 07/09/2017 à 20:54
Citation Envoyé par adiGuba Voir le message
Oui mais s'ils comptent "tuer" OpenJDK ils peuvent le faire dès maintenant.
Pas besoin d'y ajouter des fonctionnalités...
Est-ce qu'ils peuvent le faire sans risquer gros à l'heure actuelle ? Sa réputation n'est pas si bonne j'ai l'impression, alors que là on a l'occasion de lui redorer le blason, de quoi offrir une meilleure marge de manœuvre pour arriver à ces fins. Un peu comme quand le gouvernement propose un truc complètement irréaliste pour faire style qu'il a fait un geste en proposant un truc moins fort mais tout aussi scandaleux. L'idée elle est là : si on arrive à la fin avec dans un état équivalent à ce qu'on a aujourd'hui, mais avec un concurrent en moins bonne position, c'est tout bénèf.
1  0 
Avatar de 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+
0  0 
Avatar de 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
0  0