Le JDK 9 semble ne pas être sur la bonne voie pour sortir le 23 mars 2017
La date de sortie de Java 9 sera-t-elle une nouvelle fois repoussée ?

Le , par Michael Guilloux

20PARTAGES

9  0 
En décembre dernier, Mark Reinhold, architecte en chef du JDK chez Oracle, a proposé de repousser la date de sortie de JDK 9 de six mois, estimant qu’il faudrait plus de temps pour finaliser Jigsaw, un projet dont l’objectif est de concevoir et mettre en œuvre un système de modules standards pour Java SE. La date de sortie de Java 9 qui a été annoncée pour le 22 septembre 2016 a donc été repoussée au 23 mars 2017. La demande de report a été validée avec le nouveau calendrier de sortie proposé par Mark Reinhold.

Conformément à la nouvelle feuille de route, 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, à la veille du début du Rampdown Phase 1, Mark Reinhold a envoyé un email de rappel à la liste de diffusion de l’OpenJDK, un email dans lequel il a donné ses objectifs pour cette étape :

« Selon le calendrier de JDK 9, la première phase du processus de Rampdown commence demain. L'objectif global de ce processus est de veiller à ce que nous corrigions les bogues qui doivent être corrigés, et que nous comprenions pourquoi nous ne corrigeons pas quelques bogues qui devraient être corrigés. Pour cette version, je propose que nos objectifs spécifiques pour cette phase soient :

- 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, et ;
- 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 écrit 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 du Rampdown Phase 1, Mark Reinhold suggère de corriger le bogue (ce qui est souhaité). 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.

Mark Reinhold a 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 que les fonctionnalités du JDK 9 devraient être finalisées 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é », a-t-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. »

Les remarques de Colebourne laissent donc croire que le JDK 9 n’est visiblement pas sur la bonne voie pour être livré le 23 mars 2017, notamment à cause du projet Jigsaw. En d’autres termes, les six mois supplémentaires demandés par Reinhold en décembre dernier n’ont pas suffi pour finaliser Jigsaw comme il l’espérait. Il voudrait tout de même livrer Java 9 conformément à la nouvelle feuille de route. Mais, même après avoir déjà été reportée, la date de sortie du JDK 9 ne devrait-elle pas une nouvelle fois être repoussée pour finaliser les fonctionnalités ?

Source : OpenJDK mailing list

Et vous ?

Qu’en pensez-vous ?
Doit-on livrer Java 9 selon le calendrier prévisionnel ou attendre la finalisation de Jigsaw ?

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