Actually… rather not.
I am currently working on preparing z2-Environment version 2.6. While it is not used by a lot of teams, where it is used we have large, modular, code bases.
This blog is packed with posts on all kinds of aspects of modularization of largish software solutions. Essentially it all boils down to isolation, encapsulation, and sharing to keep complexity under control by separating inner complexities from the “public model” of a solution, in order to foster long-term maintainability and ability to change and extend.
Modularization is a means of preserving structural sanity and comprehensibility over time.
That said, modularization is a concern of developing and evolving software solutions – not libraries.
The Java 9 module system is however exactly that: A means to express relationships between JAR libraries within JAR libraries. I wrote about it before a while back (Java Modularity – Failing once more?). Looking at it again – I found nothing that makes it look more useful.
First of all very few libraries out there will have useful module descriptors – unless they work together trivially anyway. Inconsistent Maven dependencies are bad enough, but can usually worked around in your own assembly. A bad or missing module descriptor essentially requires you to change an existing library.
Even, if all was good, clean, consistent with our popular third-party libraries, what problem would those module-infos and the module system actually solve for us?
The only effective means to really hide implementation details to the extent of keeping definitions completely out of visibility, the means to very controlled expose definitions, even if other versions of identically-named definitions are present in the system is still a class loader based modularization approach. Java 9 modularization does not preclude that. It does not add anything useful either as far as I can tell.
Z2 v2.9 will not have explicit integration for Java 9 module system for now – for lack of usefulness.
z the world 