que - javafx tutorial

El paquete entra en conflicto con los módulos automáticos en Java 9

Question

Con Java 9 en el horizonte cercano, pensé que sería un buen ejercicio de aprendizaje transferir algunos de mis proyectos a Java 9. En uno de mis proyectos tengo dependencias para rxjava y rxjavafx

dependencies {
    compile ''io.reactivex:rxjava:1.2.6''
    compile ''io.reactivex:rxjavafx:1.0.0''
    ...
}

Quiero crear este proyecto como un módulo con nombre. Para hacer esto, necesito crear un archivo module-info.java y debo especificar los requisitos para rxjava y rxjavafx aquí. Sin embargo, estas bibliotecas aún no tienen información de módulo.

Para solucionar esto, he leído que necesito crear módulos automáticos . Por lo que entiendo, necesito cambiar el nombre de los rxjava y rxjavafx para tener un nombre simple y luego enumerar los jars en el parámetro --module-path . Luego agrego una directiva requires en mi module-info.java con los nombres de jar.

module com.foo.bar {
    requires rxjavafx;
    requires rxjava;
}

Escribí una tarea gradle para editar los nombres de jar para mí, y parece estar funcionando en la mayoría de los casos. Toma todos los frascos que deben compilarse y los renombra para no incluir información de versión o barras. Los archivos se concatenan en una cadena separada:

tasks.withType(JavaCompile) {
    delete { delete ''/tmp/gradle'' }
    copy {
        from configurations.compile + configurations.testCompile
        into ''/tmp/gradle''
        rename ''(.*)-[0-9]+//..*.jar'', ''$1.jar''
        rename { String fileName -> fileName.replace("-", "") }
    }
    options.compilerArgs += [''--module-path'', fileTree(dir: ''/tmp/gradle'', include: ''*.jar'').getFiles().join('':'')]
}

Naturalmente, las bibliotecas rx comparten algunos de sus nombres de paquete ... sin embargo, esto hace que el compilador regrese errores como:

error: module  reads package rx.subscriptions from both rxjava and rxjavafx
error: module  reads package rx.schedulers from both rxjava and rxjavafx
error: module  reads package rx.observables from both rxjava and rxjavafx
error: module rxjava reads package rx.subscriptions from both rxjavafx and rxjava
error: module rxjava reads package rx.schedulers from both rxjavafx and rxjava
error: module rxjava reads package rx.observables from both rxjavafx and rxjava
error: module rxjavafx reads package rx.subscriptions from both rxjava and rxjavafx
error: module rxjavafx reads package rx.schedulers from both rxjava and rxjavafx
error: module rxjavafx reads package rx.observables from both rxjava and rxjavafx

Parece que la única forma de rxjava este problema sería volver a empaquetar el contenido de rxjava y rxjavafx en un solo jar y agregarlo como un solo módulo. Sin embargo, esto no parece ser una buena solución ...

Entonces mis preguntas son:

• ¿Estoy usando el nuevo sistema de módulos correctamente?
• ¿Qué puedo hacer sobre este error? y
• ¿Estas dependencias me impiden actualizar o debería esperar a que rx actualice sus bibliotecas?

Nota: He intentado ejecutar esto con java / javac estándar y causan los mismos problemas. También aquí está mi versión de Java:

java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+140)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+140, mixed mode)

Answer 1

¿Estoy usando el nuevo sistema de módulos correctamente?

Si. Lo que está viendo es el comportamiento previsto, y esto se debe a que los módulos JPMS no permiten paquetes divididos.

En caso de que no esté familiarizado con el término "paquetes divididos", esencialmente significa dos miembros del mismo paquete provenientes de dos módulos diferentes.

Por ejemplo:
com.foo.A (desde moduleA.jar)
com.foo.B (desde moduleB.jar)

¿Qué puedo hacer sobre este error?

Tienes dos opciones:

1. (más difícil) "no dividir" las dependencias del paquete. Sin embargo, esto podría ser difícil o imposible si no está familiarizado con el funcionamiento interno de la biblioteca.
2. (más fácil) combine los dos frascos en un solo frasco (y, por lo tanto, un solo módulo automático) como mencionó anteriormente. Estoy de acuerdo en que no es una "buena" solución, pero tener paquetes divididos en primer lugar tampoco es una buena idea.

¿Estas dependencias me impiden actualizar o debería esperar a que rx actualice sus bibliotecas?

Con suerte, rx eventualmente actualizará sus bibliotecas para no tener paquetes divididos en algún momento en el futuro. Hasta entonces, mi recomendación sería romper los dos frascos en un solo frasco (opción # 2).

Answer 2

He estado enfrentando el mismo problema con el paquete de lectura java.transaction.xa de javaee y java.transaction.xa. Y lo arreglé agregando esta línea a mi modul-info.java

 opens javax.transaction.xa;

Funcionó bien, pero apareció una pista que dice que el paquete javax.transaction.xa está vacío o no existe. sin embargo, el código fuente se compila correctamente.

Answer 3

Tuve un problema similar:

error: module flyway.core reads package javax.transaction.xa from both jboss.transaction.api.1.2.spec and java.sql
error: module slf4j.api reads package javax.transaction.xa from both jboss.transaction.api.1.2.spec and java.sql
error: module hibernate.core reads package javax.transaction.xa from both jboss.transaction.api.1.2.spec and java.sql
.../src/main/java/module-info.java:1: error: module eu.com.x reads package javax.transaction.xa from both java.sql and jboss.transaction.api.1.2.spec

Podría deshacerme del problema de compilación de paquetes divididos comprobando las dependencias transitivas de mi proyecto ("dependencias gradle" o "dependencia mvn: árbol" podrían ser útiles) y excluyendo por código similar a:

configurations.all {
    exclude group: ''org.jboss.spec.javax.transaction'', module: ''jboss-transaction-api_1.2_spec''
}

o

<dependencies>
    <dependency>
      <groupId>org.hibernate</groupId>
      <artifactId>hibernate-core</artifactId>
      <version>5.2.10.Final</version>
      <exclusions>
        <exclusion>
          <groupId>org.jboss.spec.javax.transaction</groupId>
          <artifactId>jboss-transaction-api_1.2_spec</artifactId>
        </exclusion>
      </exclusions> 
    </dependency>
  </dependencies>

No fue necesario reempacar el frasco en mi problema. Este problema no ha ocurrido en # JDK8. Probablemente excluir dependencias no ayuda en todos los proyectos.