Package Conflicts with Automatic Modules in Java 9

Package conflicts with automatic modules in Java 9

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:

1. (harder) "unsplit" the package dependencies. However this could be difficult or impossible if you are not familiar with the inner workings of the library
2. (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).

JDK9 Automatic Modules and Split Packages Dependencies

Ok I finally managed to solve it like this:

1. Create a new maven module called hamcrest-all and add dependencies on hamcrest-core and hamcrest-library.
2. add maven-assembly-plugin to this module with appendAssemblyId set to false.
3. remove the dependency to hamcrest-core and hamcrest-library from other maven modules and instead add dependency to hamcrest-all.
4. exclude hamcrest-core and hamcrest-library when including dependency to hamcrest-all.

What it actually does is that it unpacks hamcrest-core and hamcrest-library in the jar file created for hamrest-all. And because each jar file is treated as one module by JMPS, the problem is gone :)

Java 9 Modules: Can automatic Modules result in larger (full) projects?

I think you misunderstood how automatic modules work. Their critical property is that you can use existing, non-modular JARs, put them on the module path and have them appear as modules for compilation or at run time.

I guess automatic modules means that each module of a project that requires a 3rd party jar will have to package that jar inside it's own modular jar.

No, not at all. Quite the opposite, you reuse existing JARs.

Modules A and B export package some.package to module C in Java 9

Looks like you've created a split package, meaning two modules (module-a and module-b in your case) contain the same package (some.package). The module system does not allow that. If you place both modules on the module path, you will get this error regardless of whether the package is exported or whether a third module depends on the other two.

The fix is, not to create modules that share the same package. This is not only a technical solution, it also improves the design by making sure each module has a specific and unique API.

How to fix the issue with Java 9 Modularity after adding dependency on mongock?

If it's worth solving this issue one could upgrade to the latest release of the artifact.

<dependency>
    <groupId>com.github.cloudyrock.mongock</groupId>
    <artifactId>mongock-spring</artifactId>
    <version>4.0.1.alpha</version>
</dependency>

You can understand what the issue means over this and this Q&A.

If you were to analyze the issue, you could straightforward notice that with the version 3.3.2, there are two artifacts that are brought in as a dependency under external libraries - mongock-spring and mongock-core. Further, if you look at the JARs, you would see their package structure is the same( i.e. both have classes within com.github.cloudyrock.mongock) and that is the reason for conflict that you see while they both are introduced in the modulepath.

Edit: Extended discussions to be moved over to #mongock/issues/212.

---

Related Topics