This chapter covers:
- the unnamed module and how it represents class path content
- automatic modules and how they help modularization
- using unnamed and automatic modules to incrementally modularize a code base
- mixing class path and module path
Depending on how smoothly your migration to Java 9 went (see chapters 6 and 7), you might have encountered a few of the more unpleasant effects of introducing a module system to an ecosystem that is old enough to order its own beer (even in the US). The good news is: It was worth it! As I briefly showed in section 1.7.1, Java 9 has a lot to offer beyond the module system. If you’re in a position to raise your project’s Java requirements to 9, you can start using them right away.
You can also finally start modularizing your project. By turning your artifacts into modular JARs you and your users can benefit from reliable configuration (see section 3.2.1), strong encapsulation (see section 3.3.1), decoupling via services (see chapter 10), runtime images including entire applications (see 14.2), and more module-related goodness. As section 9.3.4 shows, you can even modularize projects that run on Java 8 and before.
Important
There are two ways to make your JARs modular:
- Wait until all your dependencies are modularized and then create module descriptors for all of your artifacts in one fell swoop.
- Start early by modularizing only your artifacts, possibly just a few of them at a time.