13.7. Creating and Using Modules – Example

src/
├── com.myapp/
│   ├── module-info.java
│   └── com/myapp/Main.java
├── com.utils/
│   ├── module-info.java
│   └── com/utils/Utils.java

In this section, we outline the folder structure necessary for developing Java modules. The folder structure shows how two modules are organized: one named 'com.myapp' and another named 'com.utils'. Each module has its own directory containing a 'module-info.java' file, which describes the module's dependencies and the packages it exports. Additionally, each module contains its Java source files. This organization is crucial for maintaining the modular nature of the project.

Think of the folder structure like organizing files in a filing cabinet. Each drawer represents a module, and within the drawer, you have labeled folders (sub-packages and source files) that contain related documents (Java files). This way, everything is neatly organized and easy to find.

module com.myapp {
    requires com.utils;
    exports com.myapp;
}

This chunk presents a sample 'module-info.java' file for the module 'com.myapp'. The 'requires' statement signifies that this module depends on 'com.utils', meaning it needs functionalities provided by this module to work correctly. The 'exports' statement indicates that the package 'com.myapp' is made accessible to other modules. This explicit declaration is crucial for the modular system to manage dependencies effectively.

Imagine you are part of a team working on a group project. You might need to refer to resources created by another team member (the 'requires' clause). By stating what you need, your team can understand dependencies, and this helps to avoid confusion about what everyone is working on (the 'exports' clause).

module com.utils {
    exports com.utils;
}

Here, we see the 'module-info.java' file for the 'com.utils' module. This module exports its own package 'com.utils', making it available for other modules to use. Unlike 'com.myapp', this module does not require any other modules. It highlights how a module can stand independently by simply providing functionalities without dependencies.

Consider 'com.utils' as a utilities shop that sells tools (functions) to anyone who needs them. The shop (module) is open for business, and anyone (other modules) can come and take the tools they need. However, it doesn't rely on any other shop to operate.

javac -d out --module-source-path src $(find src -name "*.java")

This command compiles the Java source files in the 'src' directory while maintaining the modular structure. The '-d out' option specifies that the compiled classes should be stored in the 'out' directory. The '--module-source-path src' tells the compiler where to find the module source code, and '$(find src -name "*.java")' identifies all Java files that need to be compiled. This ensures that all modules are correctly compiled and organized.

Think of this command like a chef preparing a meal from multiple ingredients stored in different locations. The chef (compiler) knows where to find the ingredients (Java files) and ensures they are blended together (compiled) into a dish (output classes) ready to be served (executed).

java --module-path out -m com.myapp/com.myapp.Main

This command runs the compiled module. The '--module-path out' option indicates where the compiled modules are located, and the '-m' option specifies which module to run, in this case, 'com.myapp', while 'com.myapp.Main' indicates the main class to execute within that module. This command allows the program to be executed using the modularized structure, ensuring that it runs with the correct dependencies and settings.

Imagine you're launching a rocket (your program) that was built using various components (modules). The launch command specifies where the rocket is stored (module path) and which specific rocket to launch (the main class). This precision is essential for a successful launch into space (execution of the program).

--