¿No se puede derivar el descriptor de módulo para los nombres de módulos generados automáticamente en Java 9?

Resuelto Dmitriy Dumanskiy asked hace 6 años • 2 respuestas

Mi proyecto depende del transporte Netty Epoll. Aquí está la dependencia:

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

El nombre del módulo generado automáticamente para esta dependencia es:

netty.transport.native.epoll

Y como la nativepalabra clave está reservada en Java 9, no puedo agregar este módulo como dependencia a mi proyecto:

module core {
    requires netty.transport.native.epoll;
}

Debido a:

module not found: netty.transport.<error>

Además, la herramienta jar --describe-moduleinforma lo siguiente:

No se puede derivar el descriptor del módulo para: netty-transport-native-epoll-4.1.17.Final-SNAPSHOT-linux-x86‌_64.jar netty.transport.native.epoll: Nombre de módulo no válido: 'nativo' no es un identificador de Java

¿Hay alguna solución? (excepto "liberar el artefacto netty correcto", por supuesto).

EDITAR :

Como solución rápida para los mantenedores, puede agregar la siguiente línea para compilar:

<manifestEntries>
   <Automatic-Module-Name>netty.transport.epoll</Automatic-Module-Name>
</manifestEntries>
Dmitriy Dumanskiy avatar Sep 30 '17 16:09 Dmitriy Dumanskiy
Aceptado

La solución a esto parece ser: -

  • Una forma posible de usar ininterrumpidamente el mismo nombre de artefacto con un nombre de módulo nuevo (diferente) podría ser empaquetar META-INF/MANIFEST.MF del artefacto con un atributo Nombre-módulo-automático que rige el nombre del módulo que se utilizará. por el descriptor del módulo cuando se convierte como un módulo automático.

O

  • Los propietarios de artefactos pueden agregar declaraciones de módulos usando module-info.javaa su JAR. (Esto podría resultar en una lenta migración ascendente)

Desde la declaración del módulo definida en las especificaciones como:

Una declaración de módulo introduce un nombre de módulo que se puede utilizar en otras declaraciones de módulo para expresar relaciones entre módulos. El nombre de un módulo consta de uno o más identificadores Java (§3.8) separados por "." fichas.


Curiosamente, las declaraciones sugieren:

En algunos casos, es posible que el nombre de dominio de Internet no sea un nombre de paquete válido. A continuación se sugieren algunas convenciones para abordar estas situaciones:

  • Si el nombre de dominio contiene un guión o cualquier otro carácter especial no permitido en un identificador (§3.8), conviértalo en un guión bajo.

  • Si alguno de los componentes del nombre del paquete resultante son palabras clave (§3.9), añádales un guión bajo.

  • Si alguno de los componentes del nombre del paquete resultante comienza con un dígito o cualquier otro carácter que no esté permitido como carácter inicial de un identificador, coloque un guión bajo como prefijo del componente.

Pero tenga en cuenta al hacerlo que el guión bajo es una palabra clave en Java9

ingrese la descripción de la imagen aquí

int _;  // is would throw an error on javac based out of JDK9
int _native; // works fine
Naman avatar Sep 30 '2017 10:09 Naman

De ahora en adelante, también puedes usar este pequeño complemento de Maven para modificar automáticamente el archivo de manifiesto en un jar de Scala en tu repositorio local de Maven: https://github.com/makingthematrix/scala-suffix

Debajo del enlace encontrará una descripción general de todo el problema y lo que necesita agregar pom.xml, pero me pidieron que también lo explicara aquí, así que aquí va:

Como ya se mencionó, Java no reconoce sufijos en los nombres de los módulos, como _2.13números de versión, y los trata como partes integrales de los nombres de los módulos. Entonces, cuando su proyecto intente usar una clase de la dependencia de Scala, buscará your.scala.dependency.2.13en lugar de solo your.scala.dependency, no podrá hacerlo y fallará.

Para solucionar este problema por su parte (es decir, sin ninguna acción por parte del creador de la biblioteca), agregue esto a la <plugins>sección de su pom.xml:

<plugin>
  <groupId>io.github.makingthematrix</groupId>
  <artifactId>scala-suffix-maven-plugin</artifactId>
  <version>0.1.0</version>
  <configuration>
    <libraries>
      <param>your-scala-dependency</param>
    </libraries>
  </configuration>
  <executions>
    <execution>
      <goals>
        <goal>suffix</goal>
      </goals>
    </execution>
  </executions>
</plugin>

¿Dónde your-scala-dependencyestá el nombre de su dependencia de Scala sin el sufijo de versión (si hay más de una, simplemente agréguelas con más <param>etiquetas)? Esto debería ser el mismo que artifactIden tu <dependency>sección.

El complemento modifica el archivo JAR de la dependencia en su repositorio local de Maven. Abre el frasco, lee META-INF/MANIFEST.MFy le agrega una línea:

Automatic-Module-Name: your-scala-dependency

Si la propiedad Automatic-Module-Nameya existe, el complemento no hace nada; asumimos que en ese caso la dependencia ya debería funcionar. Esto evita que el complemento modifique el mismo archivo JAR más de una vez.

makingthematrix avatar May 05 '2021 08:05 makingthematrix