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