JDK 9 : toutes les fonctionnalités ont été implémentées et la phase Rampdown entamée
Pour la correction de bogues de priorité P1-P3

Le , par Michael Guilloux, Chroniqueur Actualités
Après plusieurs reports, le JDK 9 se dirige tout droit vers sa version stable. Mark Reinhold, l’architecte en chef du JDK chez Oracle, a en effet annoncé que toutes les fonctionnalités ont maintenant été implémentées et intégrées dans le master forest, où réside le code source officiel. Les fonctionnalités ont été gelées, c'est-à-dire qu'ils ne vont plus en ajouter, mais plutôt se concentrer sur la correction des bogues existants sans risquer d'en ajouter de nouveaux. Cela annonce donc le début de la phase de Rampdown.

Mark Reinhold avait essayé d’entamer cette phase en septembre dernier, conformément à la nouvelle feuille de route après le premier report de la date de sortie du JDK 9. L’architecte en chef du JDK chez Oracle avait envoyé un email à la liste de diffusion OpenJDK pour donner ses objectifs pour cette nouvelle étape. Cette décision n’était toutefois pas réaliste d’après un développeur open source et architecte Java, qui a fait remarquer que les fonctionnalités majeures du JDK 9 n’étaient pas encore toutes finalisées. Cela a donc conduit à un nouveau report de la sortie du JDK 9 et au décalage du reste calendrier. Maintenant que les fonctionnalités sont finalisées, on peut donc aller de l’avant.

« En fin décembre, nous avons terminé l'étape Feature Extension Complete », écrit Mark Reinhold dans son email. Il s'agit de l'étape à laquelle les JEP et petites améliorations qui ont reçu un délai supplémentaire doivent être implémentées et intégrées dans le master forest. « Nous sommes maintenant dans la première phase du processus de Rampdown, dans lequel nous cherchons à corriger les bogues qui doivent être corrigés et à comprendre pourquoi nous n'allons pas corriger certains bogues qui devraient peut-être être corrigés », a-t-il ajouté.

Pour cette étape, les objectifs spécifiques définis par Mark Reinhold sont les suivants :

  • corriger tous les bogues P1-P3 qui sont nouveaux dans le JDK 9 ;
  • corriger des bogues P1-P3 supplémentaires ciblés pour JDK 9 si le temps le permet ;
  • reporter explicitement les bogues P1-P2 qui sont nouveaux dans le JDK 9, mais qui ne pourront pas, pour une bonne raison, être fixés dans le JDK 9.

« Les bogues P4-P5 devraient, en général, être laissés pour les versions futures à moins qu'ils ne concernent seulement la documentation, les démos, ou les tests. Dans ces cas, ils doivent être identifiés comme tels avec les étiquettes "noreg-doc", "noreg-demo", et "noreg-self", respectivement », a rappelé l’architecte en chef du JDK chez Oracle.

À ceux qui sont responsables de la correction d’un bogue dans la liste de bogues à corriger au cours de la première phase de Rampdown, Mark Reinhold souhaite que le bogue soit corrigé. Si le bogue n’est pas nouveau dans le JDK 9 et que pour une raison il ne peut être corrigé, il demande au responsable du bogue de le retirer de la liste des bogues à corriger dans le JDK 9 ou de spécifier une version future dans laquelle il pourra être corrigé. S’il s’agit d’un bogue P1 ou P2 nouveau dans le JDK 9, le responsable peut faire une demande pour que la correction soit reportée à une prochaine version. Reinhold a exhorté les responsables de la correction des bogues à ne pas changer la priorité d'un bogue afin de le retirer de la liste. « La priorité d'un bogue 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 », dit-il.

Les fonctionnalités ont été gelées, mais le JDK 9 reste ouvert à certaines améliorations si elles sont vraiment justifiées. D’après Mark Reinhold, « de petites améliorations aux nouvelles fonctionnalités seront prises en compte. Les améliorations à faible risque qui ajoutent des petites fonctionnalités manquantes ou améliorent l'utilisabilité peuvent être approuvées, en particulier lorsque les commentaires des développeurs le justifient. » Pour ce qui est des « améliorations qui ajoutent de nouvelles fonctionnalités importantes, [elles] nécessiteront une justification très forte ». Mais celles qui concernent les tests ou la documentation « ne nécessitent pas d'approbation préalable. »

La version finale du JDK 9 est attendue le 27 juillet 2017, conformément au calendrier dont les étapes en cours et à venir sont les suivantes :

  • 05/01/2017 - Rampdown Start : les Rampdown sont des étapes qui permettent d’appliquer « des niveaux de contrôles croissants » aux changements entrant dans la nouvelle version du JDK. Cette première phase de Rampdown vise à corriger les bogues de priorité P1-P3 ;

  • 09/02/2017 - All Tests Run : tous les tests prévus ont été exécutés, au moins une fois, sur toutes les plateformes supportées ;

  • 16/02/2017 - Zero Bug Bounce : le carnet de bug est complètement pris en compte. Aucun des bugs qui doivent être encore corrigés avant la disponibilité générale de la version ne date de plus de 24 heures, les autres bugs sont reportés à une prochaine version ;

  • 16/03/2017 - Rampdown Phase 2 : à cette deuxième Rampdown, seuls les bugs bloquants peuvent être corrigés ;

  • 06/07/2017 - Final Release Candidate : la date à laquelle la dernière RC doit être proposée et soumise aux tests. Une ou plusieurs RC seront proposées après le Zero Bug Bounce ;

  • 27/07/2017 - General Availability : la version finale, prête pour l'utilisation en production.

Source : OpenJDK Mailing List

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

JDK 10 : le projet pour l'implémentation de la plateforme Java 10 est ouvert, qu'attendez-vous de cette nouvelle version ?
Les futures fonctionnalités de JavaFX pour la version 10 de la plateforme Java déjà en discussion sur la liste de diffusion de l'OpenJFX
Gartner proclame l'obsolescence de Java EE sur le marché des plateformes d'applications, partagez-vous cet avis ?


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


 Poster une réponse

Avatar de Stéphane le calme Stéphane le calme - Chroniqueur Actualités https://www.developpez.com
le 13/02/2017 à 22:19
JDK 9 atteint le milestone Feature Extension Complete,
les JEP qui ont reçu un délai supplémentaire sont désormais implémentés et intégrés dans le master forest

La sortie initiale de JDK 9 avait été annoncée pour le 22 septembre 2016. Mais Mark Reinhold, architecte en chef du JDK chez Oracle, a demandé un délai supplémentaire de six mois pour la finalisation de Jigsaw, un projet dont l’objectif est de concevoir et de mettre en œuvre un système de modules standards pour Java SE. Après validation de sa proposition, la date de sortie de Java 9 a donc été repoussée au 23 mars 2017, avec donc un décalage dans le reste du calendrier.

« Nous avons fait beaucoup de progrès sur le projet Jigsaw, l’élément clé de cette version, au cours des huit derniers mois. [...] Malgré ces progrès, à ce stade, il est clair que Jigsaw a besoin de plus de temps. Nous avons récemment reçu des commentaires critiques qui ont motivé une refonte de la fonctionnalité package-export du système de module, sans laquelle nous ne pourrions pas atteindre l'un de nos principaux objectifs. Il existe, en plus de cela, de nombreux problèmes de conception non encore résolus, qui nécessitent du temps pour y travailler », a expliqué Reinhold en septembre dernier, précisant que le nombre de bogues ouverts qui sont nouveaux dans le JDK 9 est également plus important que celui dans le JDK 8. Aussi, il a pu obtenir une rallonge dans le délai de livraison de la version finale de JDK 9 qui est prévue pour le 27 juillet de l’année en cours.

Selon la feuille de route communiquée par Reinhold, en décembre dernier, JDK 9 a atteint l’étape Feature Extension Complete (les JEP et petites améliorations qui ont reçu un délai supplémentaire ont été implémentés et intégrés dans le master forest). Reinhold l’a d’ailleurs confirmé dans un message sur la liste de diffusion du projet.

Le 19 janvier, Reinhold a annoncé que le projet est entré dans la première phase du processus Rampdown, des étapes qui permettent d’appliquer « des niveaux de contrôles croissants » aux changements entrant dans la nouvelle version du JDK. Cette première phase de Rampdown vise à corriger les bogues de priorité P1-P3 : il l’a décrit comme un processus durant lequel « nous visons à corriger les bogues qui doivent être corrigés et à comprendre pourquoi nous n'allons pas corriger certains bogues qui devraient peut-être être corrigés ».

À ce stade du projet, l'ensemble des fonctionnalités est gelé, a expliqué Reinhold, et il est « hautement improbable » que d'autres JEP soient ciblés pour la version JDK 9. Bien que de petites améliorations aux nouvelles fonctionnalités seront prises en considération, « la barre est désormais beaucoup plus élevée ». Les membres de la communauté peuvent demander l'approbation de ce type d'améliorations par le biais du processus FC-extension existant. Ces améliorations peuvent être incluses si elles représentent un faible risque à condition qu’elles ajoutent de petites quantités de fonctionnalités manquantes ou améliorent l'ergonomie, « en particulier lorsqu’elles sont justifiées par un feedback de développeurs ».

En outre, il a expliqué que les améliorations qui ajoutent de nouvelles fonctionnalités importantes nécessiteront des justifications beaucoup plus importantes. Quant aux améliorations des tests ou de la documentation, elles ne vont pas nécessiter de telles justifications.

Source : message de Mark Reinhold
Avatar de Askeridos Askeridos - Membre du Club https://www.developpez.com
le 14/02/2017 à 7:33
JDK 9 atteint le milestone Feature Extension Complete,
les JEP qui ont reçu un délai supplémentaire sont désormais implémentés et intégrés dans le master forest
Yeah, tous ces termes me mettent de bonne humeur ce matin. Ve masteuw fowest, le maïlessetaune genre les mecs ça fait plus pro , ça m'donne envie de revoir la saison 1 de Stargate SG-1.
Avatar de Pill_S Pill_S - Membre expert https://www.developpez.com
le 14/02/2017 à 11:21
Citation Envoyé par Askeridos Voir le message
ça m'donne envie de revoir la saison 1 de Stargate SG-1.
Eclate-toi, Teal'c...

Ch'ai pas mais c'est des termes tellement esotériques? J'ai l'impression qu'on en pond à la chaîne des biens pires...

Moi je salue quand même l'arrivée (bien que tardive ^^) d'une release majeure de Java et de quelques fonctionnalités qui vont être bien pratiques (byebye OSGi)
Avatar de GordonFreeman GordonFreeman - Membre à l'essai https://www.developpez.com
le 14/02/2017 à 14:25
On l'aura notre JDK9

Pas mal de changement intéressant dans cette nouvelle mouture.
Pour ceux qui seraient intéressé à connaître l'ensemble des changements/évolutions : http://openjdk.java.net/projects/jdk9/

@Pill_s : je suis pas sûr Qu'OSGI disparaisse de si tôt,
Je sait que le JDK9 apporte le projet Jigsaw qui est censé apportée de la modularité mais concrètement je n'ai toujours pas compris si cela remplacera réellement OSGI.
Perso je n'en ai pas l'impression mais à voir plus en détails.

Si quelqu'un à plus d'info sur la question je suis preneur .
Avatar de Mickael_Istria Mickael_Istria - Membre chevronné https://www.developpez.com
le 18/02/2017 à 13:05
Citation Envoyé par Pill_S Voir le message
(byebye OSGi)
C'est a peu pres impossible car:
1. Les applis modulaires qui veulent etre backward-compatible ne pourront pas utiliser Jigsaw et devront utiliser OSGi
2. Jigsaw ne gere pas vraiment de "lifecycle" des modules, ou en tout cas ne laisse pas le developpeur s'appuyer dessus pour gerer son appli (c'est un point tres important en IoT)
3. Jigsaw ne dispose pas d'une couche service comme OSGi
4. OSGi a deja beaucoup d'utilisateurs, notamment des tres difficiles -politiquement parlant- a migrer (comme les use-cases embarques)
5. J'attends de voir si les developpeurs Java "finaux" vont vraiment avoir quelque chose a faire de Jigsaw pour leurs apps. Au final, les applis sont deja quasiment toutes dans des conteneurs modulaires genre OSGi ou Java EE, donc ajouter la modularite a la couche de la JVM ne devrait pas leur changer grand chose.

Les raisons techniques (1,2,3) rendent par exemple entre impossible et inutile la migration d'applis existantes comme Eclipse ou Karaf

Au final, j'imagine que seule les applis neuves visant vraiment les perfs optimales (donc l'embarque) vont rapidement adopter Jigsaw, et encore, il faudra attendre que Java 9 soit considere comme robuste avant qu'ils y passent. Pour le dev Java workstation ou serveur, la valeur de Jigsaw est tres faible et inferieure a OSGi.
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 22/02/2017 à 16:51
Oracle prépare les développeurs à la migration vers Java 9
la documentation Early Access pour le JDK 9 est disponible en ligne

La sortie de Java 9 est prévue pour le mois de juillet 2017 et depuis le mois dernier, les fonctionnalités ont été gelées pour entamer la phase de Rampdown. Au cours de cette étape, les équipes qui travaillent sur le développement du JDK 9 vont se concentrer sur la correction des bogues, en particulier les bogues de priorité P1-P3 qui sont nouveaux dans cette version, et d’autres bogues de priorité P1-P3 si le temps le permet.

Ce nouveau virage annonce donc de manière imminente la sortie de la prochaine version du JDK repoussée plusieurs fois. De son côté, Oracle veut préparer les développeurs à la migration vers Java 9. Pour cela, la firme de Redwood City a récemment publié la documentation Early Access pour le JDK 9. En plus de fournir un guide de migration de Java 8 vers Java 9, cette documentation présente les nouveautés dans la nouvelle version de la plateforme Java.

« Chaque nouvelle version de Java SE introduit des incompatibilités dans les binaires, les sources et les comportements avec les versions précédentes », explique Oracle. Le but de ce guide de migration est donc d’aider les développeurs à identifier les problèmes potentiels et de leur faire des suggestions sur la façon de procéder pour migrer une application Java existante vers JDK 9.

Les changements les plus importants dans le JDK 9 viennent du projet Jigsaw pour la modularisation de la plateforme Java SE. Cette fonctionnalité « apporte de nombreux avantages, mais aussi de nombreux changements », indique Oracle. « Tout code qui utilise uniquement les API officielles de la plateforme Java SE et les API JDK spécifiques prises en charge doit continuer à fonctionner sans modification. » Par contre, « un code qui utilise certaines fonctionnalités ou des API internes au JDK peut ne pas s'exécuter ou peut donner des résultats différents. » Pour préparer la migration, Oracle suggère de télécharger la dernière build Early Access du JDK 9. Il faut noter que ces builds sont destinées à être utilisées dans des environnements de test, pas en production.

Avec la build Early Access, Oracle recommande d’exécuter l’application que vous souhaitez migrer avant de recompiler, et de voir ce qui se passe. Si votre programme utilise uniquement des API Java SE standard, il devrait pouvoir s'exécuter sans aucune modification. Si l’application est lancée avec succès, il est conseillé d’examiner attentivement vos tests et vous assurer que le comportement est le même qu’avec le JDK 8. Certains utilisateurs ont en effet remarqué que leurs dates et devises sont formatées différemment.

Les étapes suivantes dans le guide de migration vers Java 9 consistent à mettre à jour les bibliothèques tierces, compiler l'application et exécuter l'analyse statique jdeps sur le code.

En ce qui concerne les outils et bibliothèques tiers, il est indiqué dans la documentation qu’il devrait exister des versions mises à jour qui prennent en charge le JDK 9. Il faudra donc consulter les sites web des fournisseurs d’outils et bibliothèques tiers pour obtenir une version de chaque bibliothèque ou outil conçue pour fonctionner sur Java 9. Si des mises à jour existent, il est conseillé de les télécharger et les installer. « Si vous utilisez un IDE pour développer vos applications, il peut vous aider à migrer le code existant », ajoute Oracle. « Les EDI NetBeans, Eclipse et IntelliJ ont tous des versions early access disponibles qui incluent le support de JDK 9. »

Pour un certain nombre de raisons spécifiques, des erreurs peuvent se produire lors de la compilation à l'aide du compilateur JDK 9. Oracle explique par exemple que la plupart des API internes au JDK sont inaccessibles par défaut, de sorte que les développeurs soient susceptibles d’obtenir des erreurs au moment de l'exécution indiquant que l'application ou ses bibliothèques dépendent d'API internes.

Pour identifier les dépendances, vous pouvez utiliser l’outil d'analyse de dépendance de Java. Oracle suggère enfin d’exécuter l'outil jdeps sur votre application. Jdeps est un outil d'analyse statique qui vous aide à savoir de quels paquets et classes dépendent vos applications et vos bibliothèques.

Outre le guide de migration, la documentation Early Access pour le JDK 9 présente les nouveautés dans la nouvelle version de la plateforme Java.

Téléchargez les builds JDK 9 Early Access

Sources : Oracle, Guide de migration vers le JDK 9, Nouveautés dans JDK 9

Et vous ?

Qu'en pensez-vous ?
Avez-vous déjà testé la build JDK 9 ? Si oui, partagez votre expérience.

Voir aussi :

JDK 10 : le projet pour l'implémentation de la plateforme Java 10 est ouvert, qu'attendez-vous de cette nouvelle version ?
Les futures fonctionnalités de JavaFX pour la version 10 de la plateforme Java déjà en discussion sur la liste de diffusion de l'OpenJFX
Gartner proclame l'obsolescence de Java EE sur le marché des plateformes d'applications, partagez-vous cet avis ?
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 21/03/2017 à 11:53
Le JDK 9 entre dans la deuxième phase de correction de bogues
dernière étape avant la sortie de la première release candidate prévue pour le 22 juin

Maintes fois retardé par le projet Jigsaw, le JDK 9 se dirige maintenant tout droit vers une version stable. En janvier, Mark Reinhold d’Oracle a annoncé que les fonctionnalités ont été gelées ; ce qui signifie qu’à ce stade, seules les petites améliorations à faible risque qui ajoutent de petites fonctionnalités manquantes ou qui améliorent l'utilisabilité sont susceptibles d’être approuvées, en particulier lorsque les commentaires des développeurs le justifient.

Le gel des fonctionnalités annonçait également le début de la première phase des tests pour le JDK 9 (Rampdown Phase 1). Deux mois après, l’architecte en chef du JDK chez Oracle, Mark Reinhold, revient pour annoncer que la deuxième phase de test (Rampdown Phase 2) a démarré, conformément au calendrier établi. L'objectif de ce processus est avant tout de s'assurer que les bogues bloquants pour la sortie du JDK 9 soient corrigés. Après, pour les autres bogues qui étaient censés être corrigés, mais qui ne pourront pas l’être, il s’agira de comprendre pourquoi cela ne sera pas fait. Mark Reinhold a donc défini les objectifs spécifiques suivants :

  • corriger tous les bogues P1-P2 qui sont nouveaux dans le JDK 9 et critiques pour la réussite de cette version ;
  • différer explicitement les bogues P1-P2 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 ;
  • laisser la correction de tous les bogues P1-P2 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. Dans ce cas, ils doivent être supprimés de la liste des bogues à corriger ou être affectés à une version future.

Les bogues P3-P5 dont les corrections affectent uniquement les tests, la documentation ou les démos pourront être corrigés jusqu’à la sortie de la première build candidate. En ce qui concerne les bogues P3-P5 dont les corrections pourraient affecter le code du JDK 9, leurs corrections seront reportées aux futures versions.

Encore une fois, Reinhold a exhorté les responsables de correction des bogues à ne pas changer la priorité d'un bogue afin de le retirer de la liste. « La priorité d'un bogue 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 », dit-il. Pour s’assurer que les correctifs soient intégrés dans le JDK sans risque, il est également demandé aux responsables de correction des bogues de soumettre leurs correctifs à des leads désignés pour demander leur approbation des correctifs avant leur intégration.

Si la phase Rampdown 2 a démarré, les objectifs spécifiques sont soumis à discussion jusqu’au 23 mars et c’est ce processus qui sera utilisé « s’il n’y a aucune objection sérieuse ». Après cette phase, la prochaine étape majeure conformément au calendrier sera la sortie de la dernière Release Candidate (RC) du JDK 9, attendue le 7 juillet prochain, suivie de la sortie de la version stable, le 27 juillet. Mais bien avant la dernière RC, il y aura une ou plusieurs builds candidates. La première est prévue pour le 22 juin prochain.

Source : OpenJDK Mailing List
Avatar de GordonFreeman GordonFreeman - Membre à l'essai https://www.developpez.com
le 21/03/2017 à 15:56
Citation Envoyé par Mickael_Istria Voir le message
C'est a peu pres impossible car:
1. Les applis modulaires qui veulent etre backward-compatible ne pourront pas utiliser Jigsaw et devront utiliser OSGi
2. Jigsaw ne gere pas vraiment de "lifecycle" des modules, ou en tout cas ne laisse pas le developpeur s'appuyer dessus pour gerer son appli (c'est un point tres important en IoT)
3. Jigsaw ne dispose pas d'une couche service comme OSGi
4. OSGi a deja beaucoup d'utilisateurs, notamment des tres difficiles -politiquement parlant- a migrer (comme les use-cases embarques)
5. J'attends de voir si les developpeurs Java "finaux" vont vraiment avoir quelque chose a faire de Jigsaw pour leurs apps. Au final, les applis sont deja quasiment toutes dans des conteneurs modulaires genre OSGi ou Java EE, donc ajouter la modularite a la couche de la JVM ne devrait pas leur changer grand chose.

Les raisons techniques (1,2,3) rendent par exemple entre impossible et inutile la migration d'applis existantes comme Eclipse ou Karaf

Au final, j'imagine que seule les applis neuves visant vraiment les perfs optimales (donc l'embarque) vont rapidement adopter Jigsaw, et encore, il faudra attendre que Java 9 soit considere comme robuste avant qu'ils y passent. Pour le dev Java workstation ou serveur, la valeur de Jigsaw est tres faible et inferieure a OSGi.
Ha ben merci, tu réponds à quelques questions que je me posait sur ce sujet.

Merci pour ces quelques éclaircissements.

Cordialement
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 02/05/2017 à 10:56
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

La version stable du JDK 9 est attendue le 27 juillet prochain, ce qui veut dire que nous ne sommes plus qu’à moins de 3 mois. Toutefois, il y a de quoi se demander si la sortie de Java 9 ne sera pas une nouvelle fois repoussée, après que Red Hat et IBM ont publiquement annoncé leur intention de voter contre le projet Jigsaw, l’un des plus grands chantiers de Java 9, qui vise à fournir un système de modules standardisé à Java. Cette initiative a été annoncée depuis Java 7, mais a été reportée jusqu’à ce qu’elle soit finalement maintenue dans Java 9. Là encore, la complexité de Jigsaw et la nécessité de mener des tests approfondis ont été à l’origine du report de la sortie de Java 9, à plusieurs reprises.

Ce qu’il est important de noter ici, c’est que le projet Jigsaw ne vise qu’à standardiser le système de modules de la plateforme Java (Java Platform Module System, en abrégé JPMS). Jigsaw n’est pas la seule ou la première initiative de systèmes de modules pour Java ; il définit simplement le système qui sera utilisé pour modulariser la plateforme et les applications qui reposent sur elle. C’est de là que viendrait donc tout le problème.

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. Et ces deux fournisseurs, IBM et Red Hat, et bien d’autres estiment que par rapport aux systèmes de modules existants, Jigsaw ne supporte pas des fonctionnalités importantes, ce qui va donc créer une fragmentation de l’écosystème Java.

Dans un billet et un document publiés le 14 avril dernier, Red Hat et Apache Maven, ainsi que d’autres membres du comité exécutif du Java Community Process, ont exprimé leurs inquiétudes relatives à Jigsaw ; lesquelles peuvent être résumées, entre autres, par les points suivants :

  • Jigsaw est une réinvention et non une standardisation. 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 ;

  • un écosystème perturbé. L'implémentation Jigsaw exigera finalement que des millions d'utilisateurs et développeurs dans l'écosystème Java subissent d'importants changements dans leurs applications et bibliothèques. 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 ;

  • fragmentation de la communauté Java. En raison de capacités d'interopérabilité insuffisantes et d'autres restrictions, ils craignent 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.). Ils estiment qu’un développeur de bibliothèque devra choisir le monde à supporter, ou faire face aux charges d'une stratégie de supporter les deux à la fois.

Dans la liste de diffusion Open JDK, Red Hat a donc annoncé qu’étant donné les problèmes mentionnés dans le billet, il votera contre l’approbation de la spécification de JPMS, donc Jigsaw, qui « n'est pas dans le meilleur intérêt de la communauté Java. » Le vote officiel devrait avoir lieu le 8 mai prochain.

IBM, également membre du comité exécutif du JCP, a tenu les mêmes propos que Red Hat : « Je crois que ce document [publié par Red Hat] démontre qu'il reste encore du travail pour rapprocher la communauté d'un accord sur la norme proposée », affirme Tim Ellison d’IBM. « Même lorsque les problèmes techniques ont déjà été discutés au sein du groupe d’experts, il incombe à ce groupe de faire tout son possible pour comprendre et résoudre toutes les différences. Si les gens estiment que leur argument n'a pas été pris en compte, il n'est pas surprenant que la frustration s’ensuive », dit-il. « Je suis personnellement déçu que la mise en révision publique ait été faite malgré les objections explicites d'un certain nombre de membres du groupe d’experts ». Pour cela, « IBM vote également "non", ce qui reflète notre position selon laquelle le JSR n'est pas prêt en ce moment pour dépasser l'étape de la révision publique », a-t-il ajouté.

Tim Ellison estime que les problèmes et préoccupations soulevés justifient une discussion et une résolution plus poussées. Il suggère donc que le travail se poursuive entre tous les membres du groupe d'experts pour traiter les problèmes documentés sur les listes de diffusion. « IBM souhaiterait voir un consensus plus approfondi au sein des membres du groupe d'experts avant que cette spécification ne passe à l'étape suivante », a-t-il conclu.

Pour traiter ces problèmes, Red Hat a suggéré dans son billet de repousser la sortie du JDK 9, s’il le faut. « Beaucoup de problèmes pourraient être résolus dans un court laps de temps. D'autres nécessitent peut-être un peu plus de temps pour réussir, mais conduiraient à une meilleure plateforme globale et à une meilleure expérience utilisateur. Un petit délai vaut le coût si l'alternative apporte une solution qui ne couvre pas tous les cas d'utilisation », a écrit Scott Skart de Red Hat.

Sources : Blog de Scott Stark (Red Hat), Open JDK mailing list

Et vous ?

Qu'en pensez-vous ?
Avatar de Vyrob Vyrob - Membre du Club https://www.developpez.com
le 02/05/2017 à 11:29
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.
Avatar de Padget Padget - Membre à l'essai https://www.developpez.com
le 02/05/2017 à 11:57
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".
Avatar de Mickael_Istria Mickael_Istria - Membre chevronné https://www.developpez.com
le 02/05/2017 à 12:18
Citation Envoyé par Vyrob Voir le message
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.
Avatar de Cafeinoman Cafeinoman - Membre éprouvé https://www.developpez.com
le 02/05/2017 à 20:28
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...
Avatar de Vyrob Vyrob - Membre du Club https://www.developpez.com
le 03/05/2017 à 9:22
Citation Envoyé par Mickael_Istria Voir le message
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.
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 06/05/2017 à 3:07
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
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 06/05/2017 à 11:26
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à ?
Avatar de steel-finger steel-finger - Membre habitué https://www.developpez.com
le 06/05/2017 à 11:42
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
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 06/05/2017 à 12:55
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?
Avatar de Mickael_Istria Mickael_Istria - Membre chevronné https://www.developpez.com
le 06/05/2017 à 13:04
Citation Envoyé par steel-finger Voir le message
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...
Avatar de Mickael_Istria Mickael_Istria - Membre chevronné https://www.developpez.com
le 06/05/2017 à 13:10
Citation Envoyé par Aurelien.Regat-Barrel Voir le message
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.
Avatar de Aurelien.Regat-Barrel Aurelien.Regat-Barrel - Expert éminent https://www.developpez.com
le 06/05/2017 à 16:54
Merci pour les précisions. C'est très similaire au fonctionnement du comité de normalisation pour C++.
Avatar de Cafeinoman Cafeinoman - Membre éprouvé https://www.developpez.com
le 06/05/2017 à 17:36
Citation Envoyé par Mickael_Istria Voir le message
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?
Avatar de Mickael_Istria Mickael_Istria - Membre chevronné https://www.developpez.com
le 09/05/2017 à 9:22
Citation Envoyé par Cafeinoman Voir le message
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.
Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 09/05/2017 à 16:34
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
Avatar de bouye 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...
Avatar de Matthieu Vergne Matthieu Vergne - Expert confirmé 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.
Avatar de Matthieu Vergne Matthieu Vergne - Expert confirmé 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.
Avatar de Stéphane le calme Stéphane le calme - Chroniqueur Actualités https://www.developpez.com
le 21/05/2017 à 14:19
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
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 ?
Offres d'emploi IT
Ingénieur statisticien H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Chef de projet technique H/F
Safran - Ile de France - Melun (77000)
Ingénieur moa logiciel H/F
Safran - Ile de France - Villaroche

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