- 9.1 The Module Concept
- 9.2 Naming Modules
- 9.3 The Modular "Hello, World!" Program
- 9.4 Requiring Modules
- 9.5 Exporting Packages
- 9.6 Modular JARs
- 9.7 Modules and Reflective Access
- 9.8 Automatic Modules
- 9.9 The Unnamed Module
- 9.10 Command-Line Flags for Migration
- 9.11 Transitive and Static Requirements
- 9.12 Qualified Exporting and Opening
- 9.13 Service Loading
- 9.14 Tools for Working with Modules
This chapter is from the book
This chapter is from the book
This chapter is from the book
9.12 Qualified Exporting and Opening
In this section, you will see a variant of the exports and opens statement that narrows their scope to a specified set of modules. For example, the java.base module contains a statement
exports sun.net to java.net.http, jdk.naming.dns;
Such a statement is called a qualified export. The listed modules can access the exported package, but other modules cannot.
Excessive use of qualified exports can indicate a poor modular structure. Nevertheless, they can arise when modularizing an existing code base. Here, the sun.net package is placed inside the java.base module because that is where it is mostly needed. However, a couple of other modules also use that package. The Java platform designers didn't want to make java.base even bigger, and they didn't want to make the internal sun.net package generally available. In a greenfield project, one can instead design a more modular API.
Similarly, you can restrict the opens statement to specific modules. For example, in Section 9.7, “Modules and Reflective Access,” on p. 515 we could have used a qualified opens statement, like this:
module v2ch09.openpkg
{
requires com.horstmann.util;
opens com.horstmann.places to com.horstmann.util;
}
Now the com.horstmann.places package is only opened to the com.horstmann.util module.