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 ? 
Envoyé par Vyrob
