Erreurs de descripteur de module Java 9 : comment gérer les noms générés automatiquement comme « natif » ?

Java 9 Impossible de dériver le descripteur de module pour les noms générés automatiquement : exploration des solutions de contournement

Dans Java 9, l'introduction de modules a donné lieu à une exigence pour définir les noms de modules selon les règles d'identification Java. Cependant, cette exigence pose un défi pour certains noms de modules générés automatiquement, en particulier ceux qui incluent le mot-clé « natif ».

Prenons le cas de la dépendance de transport Netty Epoll :

<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-transport-native-epoll</artifactId>
    <version>${netty.version}</version>
    <classifier>${epoll.os}</classifier>
</dependency>

Le nom du module généré automatiquement pour cette dépendance est "netty.transport.native.epoll", ce qui viole les règles d'identification Java en raison de la présence du "natif". mot-clé.

Pour résoudre ce problème, une solution de contournement potentielle consiste à modifier le fichier META-INF/MANIFEST.MF de l'artefact pour inclure l'attribut Automatic-Module-Name . Cet attribut définit le nom du module tel qu'il doit être utilisé dans le descripteur du module :

<manifestEntries>
   <Automatic-Module-Name>netty.transport.epoll</Automatic-Module-Name>
</manifestEntries>

Cependant, cette solution nécessite une collaboration avec les propriétaires de l'artefact, ce qui en fait une option moins immédiate.

Un Une approche alternative consiste à demander aux propriétaires d'artefacts d'inclure des déclarations de module en utilisant module-info.java dans leurs JAR. Cette action déclenche un processus de migration ascendant, dans lequel les dépendances qui ne fournissent pas d'informations sur le module sont supposées exporter tous les packages.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!