concept directive in category java

This is an excerpt from Manning's book The Java Module System. Login to get full access to this book.

A module the.name { } block defines a module. The name typically follows the package-naming convention: it should be globally unique by reverting a domain name, it’s all lowercase, and sections are separated by dots (see section 3.1.3 for more—I use shorter names only to make them more amenable for this book). Inside the module block, requires directives express the dependencies between modules, and exports directives define each module’s public API by naming the packages whose public types are to be exported.

Listing 3.1 DisconnectedServiceObserver, accessible by monitor

// --- TYPE DisconnectedServiceObserver ---
package monitor.observer;

public class DisconnectedServiceObserver  //    #1  
  implements ServiceObserver {
 // class body truncated
}

// --- MODULE DECLARATION monitor.observer ---
module monitor.observer {
 exports monitor.observer;  //  #2  
}

// --- MODULE DECLARATION monitor ---
module monitor {
 requires monitor.observer;  //  #3  
 // other requires directives truncated
}

copy

Figure 10.3 At the center of using services is a specific type, here called Service. The class Provider implements it, and the module containing it declares that with a provides — with directive. Modules consuming services need to declare that with a uses directive. At run time, they can then use the ServiceLoader to get instances of all providers for a given service.

A package can be opened by adding a directiveopens ${package} to the module declaration. At compile time, opened packages are strongly encapsulated: there’s no difference between them being opened or not opened. At run time, opened packages are fully accessible, including nonpublic classes, methods, and fields.