Package conflicts with automatic modules in Java 9

flakes :

With Java 9 on the close horizon I thought it would be a good learning exercise to port some of my projects over to Java 9. In one of my projects I have dependencies for rxjava and rxjavafx

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

I want to create this project as a named-module. To do this I need to create a module-info.java file and I need to specify the requirements for rxjava and rxjavafx here. However, these libs don't have any module info yet.

In order to work around this I've read that I need to create Automatic Modules. From what I understand, I need to rename the rxjava and rxjavafx jars to have a simple name and then list the jars in the --module-path parameter. I then add a requires directive in my module-info.java with the jar names.

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

I wrote a gradle task to edit the jar names for me, and it appears to be working in most cases. It takes all the jars that need to be compiled and renames them to not include version-info or slashes. The files are then concatenated into a : separated string:

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(':')]
}

Naturally the rx libraries share some of their package names... this however causes the compiler to spit back errors such as:

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

It seems like the only way to get around this issue would be to re-package the contents of rxjava and rxjavafx into a single jar and add that as a single module. This doesn't seem like a good solution though...

So my questions are:

Am I using the new module system correctly?
What can I do about this error? and
Do these dependencies prevent me from updating, or should I just wait for rx to update their libs?

Note: I've tried running this with standard java/javac and they cause the same issues. Also here is my java version:

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)

Andy Guibert :

Am I using the new module system correctly?

Yes. What you are seeing is intended behavior, and this is because JPMS modules do not allow split packages.

In case you are not familiar with the term "split packages" it essentially means two members of the same package coming from two different modules.

For example:
com.foo.A (from moduleA.jar)
com.foo.B (from moduleB.jar)

What can I do about this error?

You have two options:

(harder) "unsplit" the package dependencies. However this could be difficult or impossible if you are not familiar with the inner workings of the library
(easier) combine the two jars into a single jar (and therefore a single automatic module) as you mentioned above. I agree that it is not a "good" solution, but having split packages in the first place is generally not a good idea either.

Do these dependencies prevent me from updating, or should I just wait for rx to update their libs?

Hopefully rx will eventually update their libs to not have split packages at some point in the future. Until then, my recommendation would be to just smash the two jars together into a single jar (option #2).