A modular primer
Before we dive into the Java 9 enhancements in this chapter, let's examine what modularity is in the context of Java.
We can define the term modular as a type of design or construction, in our context, of computer software. This type of software design involves a set of modules that collectively comprise the whole. A house, for example, can be built as a single structure or in a modular fashion where each room is constructed independently and joined to create a home. With this analogy, you could selectively add or not add modules in the creation of your home. The collection of modules, in our analogy, becomes the design of your home. Your design does not need to use every module, only the ones you want. So, for example, if there are basement and bonus room modules and your design does not include those modular rooms, those modules are not used to build your home. The alternative would be that every home would include every room, not just the ones that are used. This, of course, would be wasteful. Let's see how that correlates to software.
This concept can be applied to computer architecture and software systems. Our systems can be comprised of several components instead of one behemoth system. As you can likely imagine, this provides us with some specific benefits:
- We should be able to scale our Java applications to run on small devices
- Our Java applications will be smaller
- Our modular code can be more targeted
- Increased use of the object-oriented programming model
- Additional opportunities for encapsulation
- Our code will be more efficient
- Java applications will have increased performance
- Overall system complexity is reduced
- Testing and debugging is easier
- Code maintenance is easier
The shift to a modular system for Java was necessary for several reasons. Here are the primary conditions of the Java platform as of Java 9 that led to the creation of the module system for the Java 9 platform:
- The Java Development Kit (JDK) was simply too big. This made it difficult to support small devices. Even with the compact profiles discussed in the next section, supporting some small devices was difficult at best and, in some cases, not possible.
- Due to the over-sized JDK, it was difficult to support truly optimized performance with our Java applications. In this case, smaller is better.
- The Java Runtime Environment (JRE) was too large to efficiently test and maintain our Java applications. This results in time consuming, inefficient testing, and maintenance operations.
- The Java Archive (JAR) files were also too large. This made supporting small devices problematic.
- Because the JDK and JRE were all encompassing, security was of great concern. Internal APIs, for example, that were not used by the Java application, were still available due to the nature of the public access modifier.
- Finally, our Java applications were unnecessarily large.
Modular systems have the following requirements:
- There must be a common interface to permit interoperability among all connected modules
- Isolated and connected testing must be supported
- Compile time operations must be able to identify which modules are in use
- Runtime support for modules
A module is a new concept and component in Java 9; it is a named collection of data and code. Specifically, modules are a collection of:
- Packages
- Classes
- Interfaces
- Code
- Data
- Resources
Key to successful implementation, a module in Java 9 is self-described in its modular declaration. Module names must be unique and typically use the reverse domain name schema. Here is an example declaration:
module com.three19.irisScan { }
Module declarations are contained in a module-info.java file that should be in the module's root folder. As one might expect, this file is compiled into a module-info.class file and will be placed in the appropriate output directory. These output directories are established in the module source code.
In the next sections, we will look at specific changes for Java 9 in regards to modularity.