Impala's approach to modularity is very weak when it comes to controlled module sharing. The problem is that Impala still follows the old hierarchical J2EE style approach to loading classes.
Anyone can write a modular system that limits the visibility of classes through modules. The hard part is how you re-enter dependencies between modules so that other classes and interfaces from one module can see another module. At OSGi, we do this by exporting and importing packages, so we have a non-hierarchical dependency graph.
In Impala, if you want to see classes in another module, your module must be a descendant or descendant of this module. That is, only their own classes and their ancestors can see modules. Now, if you want to share some classes with your sibling module (for example, with the library you use), you must move this library to the class path of your common ancestor. In the worst case, you need to move it directly to the root module. Now the library is visible to ALL other modules, regardless of whether they want it or not! Indeed, if another module wanted to use a different version of the library, they would be forbidden to do this.
If you simply have a copy of the library in every place where it is used, then you cannot use modules using this library to communicate with each other. They will receive ClassCastExceptions when they try to pass objects to each other.
A similar problem is inherent in J2EE if two web applications need to use the same library. Typically, J2EE developers simply copy the library, but this creates “silo” applications that cannot communicate with each other. This is simply not the way to create modular software.
Stephen's glasses also seem appropriate. As far as I can tell, nobody uses Impala aside from their author.