Here are the steps to create a module in Java 9. Before you start with step 1, I should mention an obvious starting point--step 0: Know what the module's purpose is. Before you begin creating a module, you should have a clear idea of what the module is for. Remember the important tenet of modular development here! Rather than having one large code base for your application, you instead break the problem down into reusable subprojects. Think reusable libraries. The main difference is that rather than the libraries just being separate JARs that are nothing more than a collection of Java packages and types, we are leveraging the concept of Java modules to group those packages and types:

1. Assign a module name: The first step to creating a module is to come up with a unique name for the module. The name should ideally describe what the module is about and the problem it solves. A Java module name should be a valid Java identifier, so you cannot use certain characters, such as hyphens and slashes. A valid package name is also a valid module name. But apart from that, any name will do as long as it is unique in an application. However, to avoid clashing names, you don't want to call a module something very generic, such as util.

The recommended practice is to use the same convention that has worked well all these years for package names in Java--using the reverse domain name pattern. It's also recommended that you use all lowercase naming for modules, just like packages. So, for example, if you are writing a String utilities module for Acme Corp, the name of the module could be something such as com.acme.stringutil.

2. Create a module root folder: Every Java module resides in its own folder, which acts as the top-level folder for the module and contains all the assets of the module. This folder is called the module root folder. The module root folder has the same name as the module. So, the root folder for the aforementioned example module has the name com.acme.stringutil. It is named exactly the same as the module name, including the periods, if any.

3. Add the module code: Inside the module root folder goes the code that belongs to the module. This begins with packages, so you start your package folders from the module root folder onward. So, if your module com.acme.stringutil has the class StringUtil.java in the package com.acme.util, the folder structure should look like this:
   

Note the difference in the file structure from the pre-Java 9 structure that we looked at before. What used to go directly into the source folders in earlier versions of Java now goes into the module root folder. As you can see from the following table, with Java 9 there's just an additional folder level with the module root folders. From the module root folder onward, there's nothing new in the way Java types are organized:

Here's a diagram representing the code structure with the modules:

4. Create and configure the module descriptor: Here's the final step! Every module comes with a file that describes it and contains metadata about the module. This file is called the module descriptor. This file contains information about the module, such as what it requires (the inputs to the module) and what the module exports (the outputs from the module). The module descriptor is always located directly at the module root folder, and it is always given the name module-info.java. That's right! A module descriptor file is actually a .java file. What do the contents of this module descriptor file look like?

Here is a barebones and minimal module descriptor for the example module--com.acme.stringutil:

        module com.acme.stringutil { 
 
        } 

The file starts with the module keyword followed by the module name and curly braces. The curly brace structure resembles other Java type declarations you should be familiar with. Note that the name of the module (following the module keyword) should exactly match the name of the module root folder.

Within the curly braces, you can optionally specify the metadata (the inputs and outputs) of the module. In the preceding example, the module descriptor is essentially empty, with nothing between the curly braces. For any real-world module you create, you will more than likely add some metadata here to configure the behavior of the module. We'll cover this metadata in more detail in Chapter 3, Handling Inter-Module Dependencies, but what you can see in the example is the bare minimum necessary and sufficient content needed for the module descriptor.

With the module descriptor file in the module root, this is the folder and file structure for our simple module:

For someone used to writing Java classes, the name of the module-info.java file might seem a bit odd at first. This is because of a couple of reasons:

• The - character here isn't a valid identifier to be used in a Java type name, and nor is it valid for the name of a .java file
• The name of the .java file usually matches the name of the public type contained in the file, but in this case, it doesn't

However, some Java developers might also find this familiar, having used a similar-looking file name that has been used in Java since Java 1.5--package-info.java. The package-info.java file is used to specify package-level configuration and annotations, and has been used for many years now, although not very widely. Both module-info.java and package-info.java files have intentionally been given invalid Java type names in order to convey their special meaning and purpose, and to separate them from the other Java types and files you'd normally create in the process of building your application.

Steps 1 to 4 in the preceding method are the four necessary steps required to create a module. Let's put these steps into action by creating an addressbook viewer application using the Java 9 modular application approach. This is a simple application that helps you view a set of contact information. Nothing too complex, but just enough for us to put all the Java modularity concepts we learn in this book into practice!