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

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

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

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

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

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

Je m'inscris !

JDK 9 : 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

80PARTAGES

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

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 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 
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.
1  0 
Avatar de 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...
1  0 
Avatar de Matthieu Vergne
Expert éminent 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.
1  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 04/06/2017 à 14:25
Bonjour,

Java9 semble s'approcher. J'utilise Karaf de longue date et après avoir relu le sujet, je pense que la notion de module de java9 et de module de OSGI sont suffisamment différentes pour ne pas être contradictoires.

J'ai vu que beaucoup de questions se posaient autour des deux notions de module.
De que j'ai conclus des mes essais avec le jdk9 et de mon expérience Karaf c'est que nous ne sommes pas du tout dans le même scope, bien qu'il y ait des usages qui se recouvre.

Je veux faire une application découpée en modules pour faciliter l'évolution la maintenance, etc. Mais que je lance comme un tout. Dans ce cas tant la notion de module de java9 que celle de OSGI peuvent faire l'affaire.

Je veux une application qui fonctionne comme un conteneur dans lequel je veux déployer des modules à la volée en arrêter les relancer les supprimer, etc. je veux qu'ils puissent interagir, se reconnaitre, etc. là le jdk9 ne le permet pas.

Pour moi l'apport de la modularité dans java9 permet essentiellement d'obtenir un runtime adapté au besoin de l'application. de définir des sous-ensembles réutilisables d'appli en appli. Alors que OSGI est plus un conteneur, et/ou un système de plug-in à chaud.

Je vais donc continuer à utiliser Karaf, aider à le faire fonctionner sur java 9. quant à l'usage que je fais du tout forcément se posera la question module java9 ou bundle OSGI. ce qui semble se dessiner c'est que les librairies de base vont probablement devenir des modules java9 alors que les composants de l'application resteront des bundles.

A+JYT
1  0