JDK 9 atteint le milestone Feature Extension Complete
Les JEP sont désormais implémentés et intégrés dans le master forest

Le , par Stéphane le calme

21PARTAGES

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

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

Avatar de Askeridos
Membre régulier 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
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
Membre averti 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
Membre émérite 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
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
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
Membre averti 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
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
Membre régulier 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
Nouveau membre du Club 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".
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web