Why is a module path better than a class path?
- Class path can get in trouble when multiple classpath elements contain the same package
- Class path is searched (linearly) every time a new class is requested
- Modules form a partition of packages
- no package can be in more than one runtime module
- Modules perform a directed search
- Once the runtime finds a module,it remembers its packages
- Never has to search for those packages again
- Class loading becomes O(1), not O(n)
So now instead Dependency List as with Classpath, we have a Module Dependency Graph which is Directed Graph on Dependencies.
Following is the Dependency Graph for java.se module which is the Entire JVM Utilities available out of the box.
Breaking a single rt.jar into modules which can be defined in the graph shown above was the reason why Java 9 release took longer than other Java releases. It must have been very difficult task for the Engineering team and hats off to them.
So what about Backward Compatibility??
All Old Codes which are not modularized (available in Classpath) will be put into a one big module called the "Unnamed Module". That module will by default
- Requires every other module
- Exports / opens every package available in that module
- Maximum compatibility with classpath behavior
This sort of behavior allows Java code to incrementally modularized when and if required.