concept split package in category java
This is an excerpt from Manning's book The Java Module System.
The module system checks whether the universe of observable modules contains all required dependencies, direct and transitive, and reports an error if something’s missing. There must be no ambiguity: no two artifacts can claim they’re the same module. This is particularly interesting in the case where two versions of the same module are present—because the module system has no concept of versions (see chapter 13), it treats this as a duplicate module. Accordingly, it reports an error if it runs into this situation. There must be no static dependency cycles between modules. At run time, it’s possible and even necessary for modules to access each other (think about code using Spring annotations and Spring reflecting over that code), but these must not be compile dependencies (Spring is obviously not compiled against the code it reflects over). Packages should have a unique origin, so no two modules must contain types in the same package. If they do, this is called a split package, and the module system will refuse to compile or launch such configurations. This is particularly interesting in the context of migration because some existing libraries and frameworks split packages on purpose (see section 7.2).
Just like the problems we’ve discussed so far, you’ll also have to work through these two issues when getting your project to work on Java 9+, but it doesn’t stop there: you’ll occasionally encounter them, even after migration, when working on code or pulling in new dependencies. Dependencies on module internals and split packages cause trouble regardless of the kinds of modules involved. You’re just as likely to encounter them with class-path code and platform modules (the migration scenario) as with application modules (a scenario in which you’re already running on Java 9 or later and are using modules).