Java 9 Modularity

Foreword

What is modularity in Java? To some, it’s a principle for development: programming to interfaces and hiding the details of implementations. This is the school of encapsulation. To others, it’s about leaning hard on class loaders to provide dynamic execution environments. This is the school of isolation. To still others, it’s about artifacts, repositories, and tooling. This is the school of configuration. Individually, these perspectives are valid, but they feel like pieces of a larger story that’s not quite clear. If a developer knows that some portion of their code is for internal use only, why can’t they hide a package as easily as hiding a class or a field? If code can be compiled and run only in the presence of its dependencies, why don’t those dependencies flow smoothly from compilation to packaging to installation to execution? If tools work only when presented with pristine self-describing artifacts, how can anyone reuse older libraries that are just plain JAR files?

Java 9 offers a coherent story for modularity by introducing modules as a first-class feature of the Java platform. A module is a set of packages designed for reuse. This simple concept has a surprisingly powerful impact on how code is developed, deployed, and run. The longstanding mechanisms for promoting and controlling reuse in Java—interfaces, access control, JAR files, class loaders, dynamic linking—all work better when packages are placed into modules.

First, modules clarify the structure of ...