Rethinking package structure

The fact that you are required to export package names from modules has an interesting implication on the way we organize our types into packages in Java 9. Historically, the package construct has been used by Java developers to provide namespaces for Java types. While these namespaces created by package names serve the purpose, at least in theory, to prevent type name collisions and to affect visibility of package-private member variables and types, they also serve a slightly more informal purpose of grouping related types for search-ability and maintainability of code.

There's an additional significance to packages in Java 9 that affects how you group your classes and other types into packages--visibility outside modules. For instance, if you need to hide type A within a module and export type B to outside the module, you are essentially required to place types A and B in two separate packages. In most cases, typical internal classes of libraries are associated with different namespaces and packages in the pre-Java 9 world anyway, so this shouldn't be a big change in the way we do this. But it's important to note that this new change could factor into our decision to place classes in one package versus another.

Now that we've seen two modules and inter-modular dependency, I'd like you to introduce you to the concept of a module graph. You'll likely see this in a lot of Java documentation over time as a good way to represent relationships between modules. The way to draw a module graph is to plot modules as nodes and the relationships between modules with an arrow. If module A depends on module B, the arrow is drawn from A to B.

Here's the module graph for the code we have in the address book application so far:

It is very simple at this time, but as we learn more about the module system and evolve our code, we'll be coming back to this module graph and adding detail to it.