Le système de modules de Java : au secours, mes dépendances ne sont pas des modules java !

Dans un article précédent, j’ai écrit sur la prise en charge minimale du système Java Platform Module System (JPMS) et sur la manière d’y parvenir. Cependant, il peut arriver encore et encore que les bibliothèques ne prennent pas en charge le système de modules Java et il n’est pas prévisible que ceux-ci seront au moins disponibles en tant que “modules automatiques” à l’avenir.

Si vous souhaitez convertir votre propre code en JPMS et dépendez de telles bibliothèques, vous devez parfois puiser dans votre sac de trucs. Dans cet article, j’aimerais aborder exactement ces dépendances et voir comment vous pouvez les gérer.

Plugin Gradle comme solution de contournement

Bien que je me sente plus à l’aise avec Maven, j’ai récemment travaillé sur la migration d’un grand projet Gradle vers des modules Java. Comme le projet est open source, il peut facilement peut être consulté sur GitHub. Dans ce projet, au début de la conversion, il y avait un grand nombre de dépendances qui ne supportaient pas le système de modules Java. Pour certains, nous avons pu trouver une solution durable en créant des pull requests (PR) directement pour les projets respectifs afin de Automatic-Module-Name compléter. J’ai déjà décrit dans le post précédent sur le sujet comment cela peut être facilement réalisé en utilisant un plugin Maven ou Gradle. Un exemple d’un tel PR peut ici être trouvé.

Cependant, il existe également des dépendances pour lesquelles un tel PR ne peut pas simplement être fourni ou pour lesquelles le PR n’est pas accepté. Peut-être avez-vous également une dépendance dont le développement ultérieur a été interrompu. Dans tous ces cas, une implémentation différente est requise. En gros, vous devez prendre soin de créer vous-même les modules Java à partir des dépendances. Il y a d’autres façons de le faire. Par exemple, vous pouvez entrer manuellement un Automatic-Module-Name-Ajoutez une entrée au manifeste du jar, puis hébergez la version modifiée dans un référentiel Maven interne. Pour le projet Gradle susmentionné, nous avons utilisé le plugin “extra-java-module-info” de Jendrik Johannes. Ceci comme Plugin open source disponible permet de créer au moment de la construction un Automatic-Module-Name Ajouter une entrée aux dépendances. Plus précisément, le plug-in est utilisé comme dans l’exemple suivant, avec chaque automaticModule(…) appelez l’identifiant Gradle de la dépendance comme premier paramètre et le nom du module à utiliser comme deuxième paramètre :

plugins {
    id("org.gradlex.extra-java-module-info")
}

extraJavaModuleInfo {
    failOnMissingModuleInfo.set(true)

	automaticModule("io.prometheus:simpleclient", 
	                "io.prometheus.simpleclient")
	automaticModule("io.prometheus:simpleclient_common",
	                "io.prometheus.simpleclient_common")
	automaticModule("io.prometheus:simpleclient_httpserver", 
	                "io.prometheus.simpleclient.httpserver")
}

Avec l’auteur du plug-in, nous avons même pu étendre considérablement le tout dans un échange très productif. En plus des modules automatiques, le plug-in a toujours été capable de créer des modules avec une module-info.java créer. Cependant, vous deviez définir manuellement des informations telles que les exportations. Grâce à de nouvelles fonctionnalités, vous pouvez désormais définir un module de manière à ce que ses packages complets soient exportés (voir plus d’informations). Cela a le grand avantage de ne pas avoir à travailler avec des modules automatiques, ce qui apporte quelques particularités, puisque, entre autres, tous les modules automatiques sont ajoutés aux dépendances “requises” d’un module dès qu’un module automatique est marqué comme “requis” dans le module-info.java est spécifié (voir Spécification Java). Encore un grand merci à Jendrik Johannes en tant que mainteneur de la bibliothèque. De mon point de vue, notre coopération a très bien montré les avantages de l’open source. Pour tous ceux qui veulent approfondir ici, Jendrik propose gratuitement plusieurs vidéos sur ce sujet et sur d’autres sujets liés à Gradle. hébergé sur YouTube.

Un problème demeure

Cependant, un dernier gros problème ne peut pas être résolu avec les implémentations présentées ici : dès qu’un JAR viole les contraintes de division de paquet du système de module Java, il ne peut pas être ajouté au modulepath. Dans ce cas, des mesures de grande envergure doivent encore être prises. Mais j’aborderai ce point dans un prochain billet.

(rme)