This is the more obvious of the two problems. We've created a new module and designed a method in a class to return a list of Contact instances. The problem is that the Contact and Address model classes are not in the module! They are in the packt.addressbook module. Compiling this module now will result in a compilation error about the two classes not found. How do we solve this?

Here's a thought. How about depending on the module that contains the classes? The packt.contact module needs the Contact and Address classes that are available in the packt.addressbook module. Could we have the packt.contact module require the packt.addressbook module? We'll of course also need the dependency the other way round. packt.addressbook needs to requires packt.contact to get the list of contacts. Can this be done? Turns out it cannot, because it introduces circular dependencies, which are not allowed by the Java module system.

The following diagram shows two circular dependency scenarios. Modules A and B depend on each other, forming a circular dependency. In the second example, to the right, module Z reads X, X reads Y, and Y, in turn, reads Z. This is also a circular dependency, now between three modules. If the Java platform encounters circular dependencies like these, it'll throw an error and fail to work:

Circular dependencies are disallowed by the Java module system because it invalidates the concept of modules having directed dependencies. Think back to the module graph we've been drawing. There is a sense in which dependencies have direction and when one module depends on another, there's a directed arrow drawn from the former to the latter. Having circular dependencies, or as they are often called, cyclic dependencies implies that the two modules are so closely tied to each other, that the idea of splitting them into two separate modules becomes moot. If one module cannot exist without the other, what's the point in having them as separate modules anyway?

It is important to have the module graph as a directed acyclic graph. This is a type of graph, which as the name says, is directed, as in you can arrange all the nodes in such a way that there is a top-down direction of all dependencies, and it is acyclic, as in there are no loops.

Since we cannot implement circular dependencies, we are left with two options to solve this problem. First option--move the model classes from packt.addressbook to packt.contact and have packt.contact export them. This way, since packt.addressbook requires packt.contact anyway, it gets to use the model classes too.

The second option is to create a separate module for the model classes and have both packt.addressbook and packt.contact require them. This also allows for other modules to possibly use the model classes. For the sake of simplicity, I'll go with the first approach and move the model classes into packt.contact for now. In a similar real-world use case, you may want to consider the anticipated usage of such shared classes to decide whether they warrant a separate module.

With the model classes in the packt.contact module, here's how the module looks:

The module-info.java needs to be updated to export the util and model packages:

    module packt.contact { 
      requires java.xml; 
      exports packt.contact.model; 
      exports packt.contact.util; 
    }