Whereas parts 1 and 2 were akin to four-course dinners, this part of the book is more like a buffet. It covers the module system’s advanced features, and you’re free to pick whatever interests you the most in whatever order you prefer.

Chapter 10 introduces services, a great mechanism to decouple users and implementations of an API. If you’re more interested in refining requires and exports—for example, to model optional dependencies—check out chapter 11. Look into chapter 12 to prepare your modules for reflective access by your favorite framework and to learn how to update your own reflecting code.

The module system doesn’t process module version information, but you can record it when building modules and to evaluate them at run time. Chapter 13 explores that as well as the reasons why there is no further support for versions, for example to run multiple versions of the same module.

Chapter 14 takes a step back from developing modules and instead sees them as input for creating custom run-time images that contain just the modules you need to run your project. Going one step further, you can include your entire application and create a single deployable unit to ship to your customers or servers.

Finally, chapter 15 puts all the pieces together. It shows you a variant of the ServiceMonitor application that uses most of the advanced features and then gives some tips for designing and maintaining modular applications before daring to portray Java’s future: a modular ecosystem.

By the way, these features aren’t advanced in the sense that they’re more complicated than the basic mechanisms. It’s that they build on top of those mechanisms and thus require a little more background knowledge of the module system. If you’ve read part 1, particularly chapter 3, you’re good to go.

(I know, I’ve said it a couple of times already, but remember that the module names I’ve chosen were cut short to make them more amenable. Use the reverse-domain naming scheme as described in section 3.1.3.)