Jusqu'à présent, Oracle a fait de la modularité un atout majeur de la plate-forme Java. L’éditeur insiste notamment sur la capacité de découper le JDK en plusieurs modules compilables dans une multitude de configurations au moment de la création du runtime, modularité qui doit également faciliter la mise à l'échelle de Java pour les petits périphériques. Cette orientation dite « transitive » de la plate-forme permettra à Java de comprendre les dépendances entre modules et éventuellement de résoudre ces dépendances transitives au moment de la compilation ou du lancement.

Selon Oracle, l’impact de la modularité sur les habitudes de codage des ingénieurs Java devrait être significatif. « Le découpage en modules affecte toutes les phases du développement : la compilation, le test, le packaging, le déploiement, l’exécution, et toutes ces opérations seront beaucoup plus connectées à l'écosystème des outils que les expressions Lambdas par exemple, grande nouveauté du JDK 8 », avait déclaré l’an dernier Alex Buckley, specification lead pour le langage de programmation Java et la Machine Virtuelle Java (JVM) chez Oracle, lors d'une présentation de Java 9 à un groupe d'utilisateurs Java de la Silicon Valley.

Des retards à répétition pour la modularité Java 

Néanmoins, Gil Tene, CTO et cofondateur d’Azul Systems, spécialiste des technologies runtime et des machines virtuelles, reste assez partagé sur l'impact de cette modularité. « Je ne crois pas que la modularisation va beaucoup modifier les pratiques de codage et la productivité », a expliqué le CTO, qui a participé au développement de Java. Celui estime notamment que l’impact ne sera pas aussi déterminant que l’introduction des expressions Lambda et de l'API Stream dans Java 8. Essentiellement basée sur Project Jigsaw, la modularisation de Java a connu quelques difficultés. Envisagée initialement pour le JDK 8 lancé en mars 2014, la modularité a été retardée au JDK 9, et lui-même a été reporté à cause de subtilités dans le système de module auxquelles ont été confrontés les développeurs.

Les observateurs ne sont pas non plus totalement convaincus par la modularité. Andy Piper, CTO du fournisseur de middleware Java Push Technology, pense même que la modularité pourrait être insuffisante et qu’elle arrive trop tard. « La modularité de Java 9 me fait penser à l’hydravion Spruce Goose de Howard Hughes : il a été conçu à une époque révolue, sa portée était trop ambitieuse et sa livraison a terriblement tardé », a déclaré le CTO, impliqué depuis 20 ans dans la plateforme Java. « De la même façon, je ne suis pas convaincu que les problèmes que la modularité essaye de résoudre font encore partie des priorités du moment, et pour ceux qui sont concernés, il existe déjà d'autres solutions ». Ajoutant : « Bien sûr que les développeurs utiliseront la modularité, car ils utilisent toujours ce qu’il y a dans le JDK ». Mais, selon lui, il est difficile de dire quels bénéfices ils en retireront. « C’est une bonne chose d’avoir une empreinte réduite, même si les capacités des périphériques ont radicalement changé depuis que la modularité Java a été conçue, c’était il y a 10 ans. Le développement modulaire est également une bonne chose, mais il est difficile d’en attendre un retour utile sans un engagement et un investissement sérieux ».

La modularité : une source de complications  

Ce n’est pas l’avis de JetBrains, le concepteur du populaire IDE IntelliJ Idea pour Java, qui se montre plus positif sur la modularité. « En tant qu’utilisateur de la modularité de Java 9 et en tant que développeur de bibliothèque, mettre la modularité en tête du langage encourage les bonnes pratiques de conception et contribue également à résoudre le dilemme entre code privé et code protégé », explique Trisha Gee, promotrice technique de Java chez JetBrains. « Une chose remarquable à propos de l'approche choisie par l'équipe JDK et l'introduction de la modularité dans Java, c'est que pour la plupart des développeurs, elle aura probablement très peu d'impact sur leur travail ou sur leur code », a-t-elle ajouté. « Si le code n'utilise pas les API internes, qui seront masquées par la modularité dans Java 9, tout devrait fonctionner comme avant », a-t-elle expliqué. « Il est inutile de modifier une application pour utiliser le système modulaire si ce n'est pas nécessaire. Mais la modularité aura des répercussions sur les bibliothèques, et de nombreuses bibliothèques ont été forcées d'utiliser les API des JDK internes - ces API justement destinées à être masquées par la modularité - afin de fournir les fonctionnalités dont les utilisateurs ont besoin ».

« En fait, la modularité pourrait submerger les développeurs car ils doivent se concentrer sur la décomposition d'un système en modules, et c’est une source de complications », a encore déclaré Andy Piper, de Push Technology. Quant à Gil Tene, le CTO et cofondateur d’Azul Systems, il fait valoir que la modularisation résout un problème de déploiement concret de Java, lequel mérite certainement d’être amélioré. « Quoi qu’il en soit, Java est sans doute le meilleur environnement du monde pour cela », ajoute le CTO. « Donc, nous améliorons un élément de Java alors que partout ailleurs, ce même défaut semble bien pire ». En guise de conclusion sous forme de boutade, il pense que pour la plupart des développeurs Java, la modularisation ne provoquera tout au plus « un haussement d'épaules ».