Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Sortie de JDK 9 : Mark Reinhold d'Oracle demande encore un délai supplémentaire de quatre mois
Estimant que Jigsaw a besoin de plus de temps

Le , par Michael Guilloux

41PARTAGES

6  0 
Comme c’était prévisible, le JDK 9 ne sera pas prêt pour être livré le 23 mars 2017, comme c’était prévu. La sortie initiale de Java 9 avait été annoncée pour le 22 septembre 2016. Mais en décembre dernier, 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 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.

Dans la nouvelle feuille de route qui a été adoptée, le développement du JDK 9 devait franchir une nouvelle phase le 1er septembre 2016 : le Rampdown Phase 1. D’après Oracle, cette étape permet d’appliquer « des niveaux de contrôles croissants » aux changements entrant dans la nouvelle version du JDK afin de corriger les bogues de priorité P1-P3. Le 31 août, Mark Reinhold a donc envoyé un email à la liste de diffusion OpenJDK pour donner ses objectifs pour cette nouvelle étape qui devait commencer le lendemain. Il a ensuite donné un délai d’une semaine (jusqu’au 7 septembre, 15 heures UTC) aux « committers » de Java 9 pour donner leurs avis au sujet de sa proposition sur la manière dont doit se dérouler le Rampdown Phase 1, en précisant que s’il n’y avait aucune objection sérieuse, le processus serait adopté.

En réponse à la proposition, Stephen Colebourne, développeur open source et architecte Java, a fait remarquer que les fonctionnalités majeures du JDK 9 n’ont pas encore été toutes finalisées, alors que la dernière feuille de route suggérait qu’elles devraient l’être le 26 mai 2016, soit plus de trois mois de retard. Pour lui, il n’est donc pas réaliste de vouloir passer à la phase 1 du Rampdown alors que le projet Jigsaw est encore très débattu et loin d’être finalisé.

« Étant donné que la fonctionnalité majeure de JDK 9 (modules/jigsaw) a encore des problèmes majeurs non résolus en suspens et que le calendrier suggère encore que les fonctionnalités auraient dû être finalisées il y a plus de trois mois (26 mai 2016), le calendrier sur lequel cet email est basé est clairement profondément vicié », avait-il répondu, en faisant référence à l’email de Mark Reinhold. Et d’ajouter : « Je suis également très mal à l'aise avec l'idée que les modules - une fonctionnalité complexe, difficile et encore très débattue - sont encore loin d'être finalisés, et pourtant sur le point d'être précipités pour répondre à un calendrier artificiel. »

Après la réponse de Stephen Colebourne, Mark Reinhold a jugé bon de ne pas précipiter la sortie du JDK 9 alors qu’il reste encore beaucoup de boulot, quand bien même d’énormes progrès auraient été faits après que la date de sortie initiale a été reportée.

« Quatre-vingt cinq JEP sont ciblés sur JDK 9. La plupart sont faits, ou presque. Nous ne sommes pas, malheureusement, où nous devons être par rapport au calendrier actuel », a-t-il dit dans un nouvel email envoyé à la liste de diffusion OpenJDK. Pour rappel, un JEP (JDK Enhancement Proposal) est un processus élaboré par Oracle pour recueillir des propositions d'améliorations pour le JDK et OpenJDK.

« 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 », explique Reinhold qui ajoute encore que le nombre de bogues ouverts qui sont nouveaux dans le JDK 9 est également plus important que celui dans le JDK 8.

Pour ces raisons, l’architecte en chef de la plateforme Java chez Oracle propose que le calendrier du JDK 9 soit prolongé de quatre mois, ce qui fera passer la date de disponibilité générale du 23 mars au mois de juillet 2017. Il compte faire une proposition plus détaillée avec la date de sortie exacte et les dates correspondant aux autres jalons au cours des semaines à venir. Mais pour l'instant, Mark Reinhold suggère de reporter le début du processus de Rampdown et de continuer avec la finalisation des fonctionnalités déjà adoptées. « Notre objectif principal devrait être d'utiliser ce temps supplémentaire pour stabiliser, polir, et affiner les fonctionnalités que nous avons déjà plutôt que d'en ajouter des nouvelles », a-t-il rappelé, en précisant que des améliorations mineures et des propositions fortement justifiées seront toutefois prises en considération, tant qu’il n’y a pas de risque pour l’ensemble du JDK 9.

Cette nouvelle proposition de changement de calendrier devrait être validée par les committers du JDK 9. Elle sera adoptée si aucune objection n’est faite jusqu’au 20 septembre, 16 heures UTC.

Mise à jour le 19 / 10 / 2016 - JDK 9 : la nouvelle date de sortie est fixée au 27 juillet 2017, après acceptation de la demande de report de Mark Reinhold

Aucune objection n’ayant été enregistrée, la proposition de report de Mark Reinhold vient d’être acceptée. La sortie de Java 9 est donc prévue pour le 27 juillet 2017. Ce qu’il faut décider à présent, ce sont les dates qui seront retenues pour les étapes intermédiaires. Mark Reinhold a donc proposé un nouveau calendrier, avec plus de détails, ce qu’il n’avait pas encore fait lors de sa dernière proposition. Le calendrier proposé est le suivant :

  • 26/05/2016 - Feature Complete : toutes les fonctionnalités ont été implémentées et intégrées dans le master forest (où réside le code source officiel), avec les tests unitaires ;
  • 22/12/2016 - Feature Extension Complete : date à 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 ;
  • 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 ;
  • 2017/02/09 - 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.

Sources : OpenJDK mailing list (proposition de report de la date de sortie), OpenJDK mailing list (nouveau calendrier)

Et vous ?

Qu’en pensez-vous ?

Voir aussi :

Java : Oracle va marquer l'API Applet obsolète dans le JDK 9, mais n'a pas l'intention de la supprimer de sitôt
Sans surprise, Oracle va repousser la date de sortie de Java EE 8, mais envisage de livrer une édition de Java SE chaque année
La date de sortie de JDK 9 sera-t-elle reportée à 2017 ? Reinhold demande un délai supplémentaire de six mois pour finaliser Jigsaw.

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

Avatar de Mickael_Istria
Membre émérite 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.
5  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 20/10/2016 à 15:19
Vous pensez vraiment qu'une communauté de volontaires serait capable de faire vivre un tel projet ?
OpenJDK marche bien, et pourrait certainement continuer sans Oracle.
Quant a Eclipse, certes IBM contribue beaucoup, mais ils sont loin d'etre majoritaires: https://eclipse.biterg.io . De la meme maniere, Eclipse arriverait a continuer sans IBM.

Si demain Java venait à vaciller, les alternatives jeunes, dynamiques et modernes pourraient finir de l'achever : NodeJS, Go (tous deux sont des merveilles pour dev des API), ...
Si tu parles d'API web, un JEE recent avec Jax-Rs et les annotations, c'est plus productif que NodeJS dans pas mal de cas. En plus, avec la mode des Wildfly Swarm et compagnie, il n'y a plus vraiment de concept de serveur donc tu te retrouves au meme grain que node.js.

J'ai l'impression que ta perception de l'ecosysteme est un peu lointaine de certaines realites (qui ont ete vraies il y a 5 ou 10 ans, mais le monde a evolue depuis).
3  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 14/09/2016 à 14:06
Qu'ils prennent le temps qu'il faut. Mieux vaut que ce soit bien fait plutôt que vite fait.
3  1 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 14/09/2016 à 18:04
Vu que je participe à un projet où on sait qu'il y a des changements de fonds à faire pour améliorer les choses mais qu'on a choisi d'autres priorités parce que pour l'instant on n'a pas de base solide pour le faire ni d'idée fiable de l'impact que ça aura sur le reste de l'architecture, je comprends tout à fait que certaines améliorations prennent des années à voir le jour.

Rien ne sert de courir, il faut partir à point, disait la chanson.
3  1 
Avatar de Cyäegha
Membre régulier https://www.developpez.com
Le 19/10/2016 à 9:55
Concernant le projet OpenJDK, ce n'est pas (en l'état) une alternative à Oracle : OpenJDK est simplement la partie open source du JDK Oracle, et la majorité des contributions au code proviennent d'employés d'Oracle. Et au delà du JDK, il y a aussi les processus de standardisation du langage Java (JCP...) qui dépendent largement d'Oracle.

Après, effectivement, il est possible de créer une alternative en forkant le code d'OpenJDK (et j’imagine que des boîtes comme IBM ou RedHat y penserait très sérieusement si Oracle venait à clairement s'en désintéresser), mais ça serait quand même une nouvelle organisation à mettre sur pied. Et si oracle ne lâchait pas la main sur les procédures et les marques commerciales, on se retrouverait avec deux plateformes divergentes (la plateforme Java "officielle" d'Oracle, et la nouvelle qui devrait se trouver un nouveau nom).
2  0 
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.
2  0 
Avatar de Matthieu Vergne
Expert éminent 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.
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 07/09/2017 à 17:24
Citation Envoyé par Matthieu Vergne Voir le message
Et c'est où qu'il prend en compte ce qui est faisable en interne ? Parce que bon, copier les autres a ses avantages, mais si c'est pour avoir en pratique le même rythme et se contenter de sortir des versions qui sont juste de moins en moins boguées, les utilisateurs resteront au rythme habituel pour éviter de perdre leur temps, en se contentant d'ignorer les versions intermédiaires.
L'intérêt c'est que les versions intermédiaires pourront proposer de nouvelles fonctionnalités plus "simple", sans avoir à dépendre du temps de développement trop important d'une autre fonctionnalités.

Par exemple si cela aurait été le cas on aurait déjà pu avoir le REPL, HttpClient avec support d'HTTP2, l'évolution de la classe Process, etc.

Citation Envoyé par Matthieu Vergne Voir le message
Ce qui veut dire qu'à terme il n'en restera qu'un seul. L'objectif, si on lit entre les lignes, et de supprimer l'un des deux. La question est alors de savoir lequel. Je vous le laisse en mille. Reste à voir ensuite l'évolution que ça engendrera, style pas en arrière sur les licences avec celui qui reste. En surface, ça semble génial, mais où sont les garanties ?
Moi je vois plutôt çà dans le sens où çà leur permettra de proposer plus facilement leur JDK commerciale.

S'ils tuent l'OpenJDK ils se prendront un gros bad-buzz, se retrouveront éjecté des distributions, et risqueraient de voir un fork...

Citation Envoyé par ParseCoder Voir le message
Dommage qu'Oracle n'ai pas choisit une license aussi libérale que la license du .NET Compiler Platform (Roslyn).
C'est à dire ?
On est sur du GPLv2 là je ne vois pas où est le problème...

a++
2  0 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 07/09/2017 à 20:38
Oracle ne faisant rien sans arriere pensée (il faut bien payer l'ile de l'insatiable ellison), du business, rien que du business dans cette strategie.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 11/09/2017 à 15:11
Citation Envoyé par Matthieu Vergne Voir le message
La position que je prend est plus celle du questionnement : qu'est-ce qui empêcherait Oracle de prendre de telles mesures aux dépends de la communauté ? À l'heure actuelle, je ne vois pas de garantie qui permette de se dire "ça c'est une bonne chose". J'ai l'impression qu'à l'heure actuelle, c'est plus une question de pari/confiance.
On peut toujours ce méfier, mais cette question n'a rien de particulier à la situation. On peut tout a fait la poser pour n'importe quel langage/société. Il n'y a pas plus de raison d'être sceptique qu'envers Microsoft, Google, Apple, Redhat, ...
2  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web