concept module graph in category java

This is an excerpt from Manning's book The Java Module System. Login to get full access to this book.

Figure 1.12 The Java Platform Module System (JPMS) in action. It does most of its work at launch time: after (1) bootstrapping, it (2) makes sure all modules are present while building the module graph, before (3) handing control over to the running application. At run time, it (4) enforces that each module’s internals are protected.

Figure 1.13 The module graph for the ServiceMonitor application is very similar to the architecture diagram in figure 1.6. The graph shows the four modules containing the application’s code, the two libraries it uses to implement its feature set, and the involved modules from the JDK. Arrows depict the dependencies between them. Each module lists some of the packages it exports.

As discussed in section 3.4, --module-path mods:libs informs the module system that the mods and libs directories contain ServiceMonitor’s application modules. The option --module monitor defines monitor as the initial module, as a consequence of which the module system will resolve all of monitor’s dependencies and build the module graph as discussed in the previous section. It will then launch the main class you set in the module descriptor during packaging in section 4.5.3: monitor.Main.

> error: package javax.xml.bind is not visible
> import javax.xml.bind.JAXBException;
>                 ^
>     (package javax.xml.bind is declared in module java.xml.bind,
>      which is not in the module graph)
> 1 error