11 Refining dependencies and APIs

Chapter 3 explains how requires and exports directives are the basis for readability and accessibility. But these mechanisms are strict: every module has to be explicitly required, all required modules have to be present for the application to compile and launch, and exported packages are accessible to all other modules. This suffices for the majority of use cases, but there’s still a significant portion in which these solutions are too broad.

The most obvious use case is optional dependencies, which a module wants to compile against but which aren’t necessarily present at run time. Spring, for example, does this with the Jackson databind library. If you run a Spring application and want to use JSON as a data-transfer format, you can get support for that by dropping in the Jackson artifact. If, on the other hand, that artifact is absent, Spring is still happy—it doesn’t support JSON then. Spring uses Jackson but doesn’t require it.

11.1 Implied readability: Passing on dependencies

11.1.1 Exposing a module’s dependencies

11.1.2 The transitive modifier: Implying readability on a dependency

11.1.3 When to use implied readability

11.1.4 When to rely on implied readability

11.1.5 Refactoring modules with implied readability

11.1.6 Refactoring modules by merging them

11.2 Optional dependencies

11.2.1 The conundrum of reliable configuration

11.2.2 The static modifier: Marking dependencies as optional

11.2.3 Module resolution of optional dependencies

11.2.4 Coding against optional dependencies

11.3 Qualified exports: Limiting accessibility to specific modules

11.3.1 Exposing internal APIs

11.3.2 Exporting packages to modules

11.3.3 When to use qualified exports

11.3.4 Exporting packages on the command line

Summary