Comme nous l’avons rapporté récemment, Red Hat et IBM ont décidé de voter contre le projet Jigsaw qui vise à fournir un système de modules standardisé à la plateforme Java. Dans un billet de blog, un ingénieur de Red Hat a exposé les raisons de cette position. Il explique que 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. Il pense également que l’écosystème Java sera perturbé, expliquant que 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. L’un des points également mis en avant par l’ingénieur de Red Hat est la fragmentation de l’écosystème. En raison de capacités d'interopérabilité insuffisantes et d'autres restrictions, il craint 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.).Dans les détails, Red Hat explique encore que les modules automatiques de Jigsaw ne sont pas bien accueillis par la communauté ; un problème qu’Oracle veut résoudre avec une nouvelle proposition. Pour information, les modules automatiques sont considérés comme un mécanisme de compatibilité qui permet de « transformer » les JAR en modules dans un environnement modulaire. L'idée est qu'un module soit généré automatiquement à partir d'un JAR ; le nom du module serait alors un nom dérivé de celui du JAR, après diverses transformations pour le faire s'aligner sur la convention de nommage proposée pour les modules. Le problème est que de nombreux membres de la communauté estiment que les modules automatiques risquent d'apporter plus de mal que de bien, notamment à cause des risques de collision de noms.
Ils ont donc suggéré à Mark Reinhold d'Oracle, Specification Lead du projet Jigsaw, de « réviser l'algorithme qui calcule les noms des modules automatiques pour inclure l'identifiant de groupe Maven, lorsqu'il est disponible dans le fichier 'pom.properties' d'un fichier JAR ». Cela devrait faire « en sorte que les noms des modules soient moins susceptibles d'entrer en collision. » Dans le cas contraire, Mark Reinhold devrait envisager de « supprimer entièrement la fonctionnalité des modules automatiques », étant donné qu’elle peut créer plus de problèmes qu’en résoudre.
Mark Reinhold a donc fait des ajustements à son plan sur les modules Java, mais propose de ne pas supprimer la fonctionnalité de modules automatiques. D’après l’architecte en chef de la plateforme Java chez Oracle, la fonctionnalité de modules automatiques est « une partie critique de toute l’histoire de migration : elle permet aux développeurs d'applications de commencer à modulariser leur propre code sans avoir à attendre que toutes les bibliothèques et les frameworks qu'ils utilisent soient modularisés », dit-il. « Les bibliothèques et les frameworks populaires qui sont activement maintenus seront éventuellement modularisés assez rapidement, mais les projets moins actifs prendront plus de temps – peut-être des années ou même des décennies – et de nombreux projets inactifs ou abandonnés ne seront jamais modularisés. » C’est en cela que les modules automatiques sont importants dans le projet Jigsaw.
Mark Reinhold ne compte toutefois pas non plus réviser l'algorithme qui calcule les noms des modules automatiques, comme cela lui a été suggéré. « La suggestion d'utiliser les coordonnées Maven lorsqu'elles sont disponibles aiderait moins de la moitié des projets les plus populaires en cours d'utilisation aujourd'hui, d'après trois enquêtes différentes », dit-il. Par contre, il propose de ramener l’attribut manifeste de fichier JAR, une option qui avait été suggérée précédemment, mais qu’il avait rejetée. « L'attribut manifeste 'Automatic-Module-Name' est, d'un point de vue technique, esthétiquement désagréable, car il définit une deuxième façon de nommer des modules. Pris seul, cependant, il permet une modularisation non coordonnée en utilisant des noms de modules stables avec peu d'effort, et donc il semble que ce soit la moins mauvaise option sur la table », a-t-il expliqué. Il recommande par ailleurs que tous les modules soient nommés selon la convention de nom de domaine Internet inversé.
La nouvelle proposition de Mark Reinhold ne résout pas complètement le problème, mais semble déjà satisfaire un bon nombre de personnes, y compris les développeurs du projet Apache Maven. « Je pense que c'est un développement formidable qui permettra d’emprunter le chemin vers la modularisation et s’éloigner de la fragmentation potentielle de l'écosystème Java », a répondu Brian Fox, ancien président du projet Apache Maven.
Il est important de noter que la proposition d'Oracle ne vient pas en réponse aux inquiétudes exprimées par Red Hat et IBM. Il s'agit en effet d'un problème sur lequel une discussion a été ouverte il y a des mois déjà.
Sources : Proposition révisée de Mark Reinhold, Réponse de Brian Fox
Envoyé par Matthieu Vergne
