8 Incremental modularization of existing projects

 

This chapter covers

  • Working with the unnamed
  • Helping modularization with automatic modules
  • Incrementally modularizing 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 may have encountered a few of the more unpleasant effects of introducing a module system to an ecosystem that’s old enough to order its own beer. The good news is it was worth it! 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 artifacts into modular JARs, you and your users can benefit from reliable configuration (see section 3.2.1), strong encapsulation (section 3.3.1), decoupling via services (see chapter 10), run-time 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.

There are two ways to make JARs modular:

  • Wait until all your dependencies are modularized, and then create module descriptors for all artifacts in one fell swoop.
  • Start early by modularizing only your artifacts, possibly just a few at a time.

8.1 Why incremental modularization is an option

8.1.1 If every JAR had to be modular …

8.1.2 Mixing and matching plain JARs with modules

8.1.3 Technical underpinnings of incremental modularization

8.2 The unnamed module, aka the class path

8.2.1 The chaos of the class path, captured by the unnamed module

8.2.2 Module resolution for the unnamed module

8.2.3 Depending on the unnamed module

8.3 Automatic modules: Plain JARs on the module path

8.3.1 Automatic module names: Small detail, big impact

8.3.2 Module resolution for automatic modules

8.3.3 All in on automatic modules?

8.3.4 Depending on automatic modules

Summary

sitemap