Java 9, Jigsaw, JPMS, and Modules: A Personal Exploration

Java 9 delayed so many times because of Project Jigsaw, and you may be heard a lot of thing about modules, modularity, and other stuff, so, what it’s all about? What the heck is modularization and what do we mean by modularized platform? Java Platform Module System (JPMS)? Is it going to be a revolution in Java ecosystem?
This post is my exploration of the most important thing that happened to the JDK, the Module System. I will explain what modularization is, why you need it, and how you can create your modularized project.


What & Why:

Maintainability is one of the most significant concerns in software design and evolution. We want a code base that is loosely coupled, highly cohesive, extremely readable and can be understandable in one eye shot. We design our classes and organize them in packages. So far so good, but when we have hundreds of packages the dependencies between them is not visible in one eye shot. Therefore, we need something more than packages to organize our code base and makes it more maintainable.
Another problem is java classpath and how it runs our codes. All jar classes and libraries are flattened into the classpath. When these jar files have multiple version of a class on the runtime, Java ClassLoader can load only one version of that class, in this way, there is ambiguity about how your program is going to work, and ambiguity is a bad thing. This issue is so frequent that it has its name called “JAR Hell.”
Another problem with classpath is that it doesn’t follow the “Fail First” principle. You may have missing classes that exist in the classpath, but it doesn’t exist in the production environment. Until the JavaClassDefError exception at runtime, you can’t be sure what is missing. Finally, The big issue with classpath is encapsulation. Every class on the classpath access to each other and this is an encapsulation violation. We want to hide our internal APIs, and that’s why we need another level of encapsulation (“Strong Encapsulation”) and control the access to our classes in our packages.
Modules are going to fix these issues. What is a module? A module has a name, it groups related code and is self-contained. A module describes explicitly what it needs from other modules and which part of him is visible to other modules. In this manner, dependencies between modules are crystal clear. We have Strong Encapsulation which means we can hide our internal APIs, and finally, we now follow the “Fail First” principle therefore when there is a missing module or confliction you will get an error.

modules meme
Modularizing JDK allows JDK developers to manage the huge complexity of it. When you write a tiny and straightforward application that doesn’t use RMI, CORBA, JavaEE, and other stuff, why you need a full, huge, and heavy Java Runtime Environment? Isn’t that wiser to have your Runtime Image that only contains the modules you need? Now with a modularized platform, it’s possible.
JDK modulesThis is how JDK now looks like. On the bottom, we have “java.base” module that every other module implicitly or explicitly depends on. As you can see, this dependency graph is a DAG which means no circular dependency allowed.

The picture below shows essentially what module is. Each module has a module descriptor called “”

Module Structure

In file you describe the name of your module, what it requires to work and which packages are visible outside this module. For example, you can see what packages java.sql exports (make visible) and which modules it requires.

java.sql module

So in the simplest form, the looks like the image below:


In the next section, I will show how you can work with these modules and create your modules.


First of all, you need to download and install Java 9. You can find it here.

Let’s build a project in IntelliJ IDEA:

The picture below shows how to create a module:

After creating a module, you need to create a file inside the src:

I’ve built a project that has two module: “com.mhrimaz.gui” and “com.mhrimaz.logic.” You can see the structure of the project in the image:

In com.mhrimaz.logic module I have two classes called “InternalGreeting” and “Greeting.”

The of com.mhrimaz.logic, is the following:

This means the package com.mhrimaz.logic (it’s a package name not a module name don’t confuse) is visible outside this module but the package com.mhrimaz.logic.internals is not visible.

The MianApplication file is a simple JavaFX program:

It seems that this package doesn’t need to export anything it only requires javafx.base and javafx.controls and in order to use Greeting class, we also should require com.mhrimaz.logic. The module-info of the com.mhrimaz.gui module looks like this:

When we run our application we will get an exception:

so obviously it tells that we need to export com.mhrimaz.gui package, This means uses MainApplication to pass the Stage to it and you need to export your package to the (Note: You can only export a package to specific module or export it to all modules)
So now the looks like this:

And the result seems like a bug in JavaFX implementation in Java 9 but this is our result:



The story doesn’t end here, There is a whole lot of details about modules, dependencies between them that you can read them in Java 9 Revealed or Java 9 Modularity book.

2 thoughts on “Java 9, Jigsaw, JPMS, and Modules: A Personal Exploration

  1. Perfect explanation. Is there any example for providing switch at run time we can start or stop exposing the classes.

    1. Thanks. Why do you need to switch exposing at run-time? If you need reflective access, you can use “opens” instead of “exports” to have reflective access, But I’m not sure that switching is possible.

Leave a Reply

Your email address will not be published. Required fields are marked *