Java SE 9: Develop and Test Implied Readability Between Modules With IntelliJ IDE (Part-5) With Examples

I have already discussed many theoretical concepts about “Java 9 Module System” and also developed couple of examples using CMD prompt and IDEs in my previous posts.Now I’m going to discuss about “How to Develop and Test Implied Readability Between Modules With IntelliJ IDEA IDE” in this post.

In this series of “Java 9 Module System” posts, it is my fifth post. Before reading this post, please go through my previous post by clicking the following links to understand some basics about Java 9 Modules.

Post Brief Table of Content:

  • What is Readability?
  • What is Accessibility?
  • What is Implied Readability?
  • Develop Module Dependency With Bad Approach
  • Test Module Dependency For Bad Approach
  • Develop Implied Readability(Good Approach)
  • Advantages of Implied Readability

What is Readability?

If Module-1 directly depends on Module-2, then it is know as “Module-1 Reads Module-2”. In other words, we can say that “Module-2 is Readable by Module-1”.

So, It is know as Readability relationship between Module-1 and Module-2. Let us explore it with some JDK 9 Modules using below diagram.


Here “java.sql” module reads “java.xml”, “java.base” and “java.logging” modules.

What is Accessibility?

If Module-1 has Readability Relationship with Module-2, then Module-1 can “Access” all Public API of Module-2. It is know as Accessibility Relationship between those two modules. As we discussed in my previous posts, a Module can have only Public API or both Public and Private API.

In simple words, Public API means Public Types. If you don’t understand it well, We will discuss on “How to develop Public and Private API” in my coming posts.

Both Readability and Accessibility concepts are the basis for achieving the two main Goals of Java 9 Module System:

  • Reliable Configuration
  • Strong Encapsulation

We can define Readability and Accessibility Relationships between modules using the following concepts:

  • exports clause
  • requires clause
  • public modifier
  • to clause

We will discuss all these concepts in this post with examples except last one (check for my coming posts).

What is Implied Readability?

If Module-1 reads on Module-2 and Module-2 reads on Module-3, then Module-1 reads Module-3. This kinds of Transitive Dependency is known as “Implied Readability” from Moudle-3 to Module-1.

It is also known as Implied Dependency.

Suppose if we have relationship between three modules as shown in the below diagram.


“LastName” Module depends on “FirstName”, “FullName” Module depends on Both Modules : “FirstName” and “LastName”. That means there is a Transitive Dependency between these three modules:
FullName ==> LastName ==> FirstName

In Java 9 Module System, We have two approaches to resolve these Module Dependencies.
1. Bad Approach
This approach solves Transitive Dependency between modules without using “Implied Readability”.

Here “FullName” imports both modules using “requires” clauses as shown below:

It is bad approach because LastName is already importing FirstName Module then why don’t we get that import feature to FullName Module?? Instead of using that, FullName is importing both modules. It works perfectly, however it’s not a recommended approach.

In real-time projects, we will have this kind of dependencies on many modules, is it good to import all modules?? Definitely NO, right.

2. Good Approach
This approach solves Transitive Dependency between modules using “Implied Readability” Technique.

Here “FullName” imports only LastName module using “requires” clause, but it gets “FirstName” automatically without importing it as shown below:

This good approach is also know as “Implied Readability” in Java 9 Module System. So we can implement “Implied Readability” using “public” modifier as shown in the above example.

We will develop both approaches in the coming sections to understand it well.

Please go through this post Java 9 HelloWorld Module with Eclipse and IntelliJ IDEs to know on “How to develop Java 9 Modules using IntelliJ IDE”.

Develop Bad Approach

In this section we will develop bad approach to solve this Transitive Dependency without using “Implied Readability”. Once we are comfortable with this approach, we will develop right approach in the coming sections.

Let us understand this approach with this digarm:

    • Create an IntelliJ IDEA Project

Project Name: ImpliedDependency

    • Develop FirstName Module Code
      • Create FirstName Module

Module Name: : com.firstname

      • Create FirstName Module Package

Package name:

      • Create Java Component(s)

  • Create FirstName Module Descriptor

    • Develop LastName Module Code
    • Create LastName Module

Module Name: : com.lastname

    • Create LastName Module Package

Package name:

    • Create Java Component(s)

  • Create LastName Module Descriptor

As this module is dependent on FirstName Module, we should add “requires” clause to that module as shown in the above example.

    • Develop FullName Module Code
    • Create FullName Module

Module Name: : com.fullname

    • Create FullName Module Package

Package name:

    • Create Java Component(s)

  • Create FullName Module Descriptor

As this module is dependent on FirstName and LastName Modules, we should add requires clauses to both of them as shown in the above example.

Develop Test Module and Test Bad Approach

In this section, we will develop a Test Module to test this Bad Approach.

    • Create Test Module

Module Name: :

    • Create Test Module Package

Package name:

    • Create Java Component(s)

  • Final Project looks like below.
  • java9_module_graph-450x340
  • Run the NameTester class


It works perfectly, however it is not a recommended approach. Let us develop same application using “Implied Readability” Technique.

Develop and Test Implied Dependency

    • Please follow same steps as we did for Bad approach.
    • Change “LastName” Module Descriptor

Here we can observe that “public” modifier before Module name. When we use this in requires clause as shown in the above Module Descriptor, that means any Module which reads this “LastName” Module can also reads “FirstName” Module automatically. No need to use extra “requires” clause.

  • Change “FullName” Module Descriptor

Here we are not using extra “requires” clause for “FirstName” Module. Still, it can reads that module because of “LastName” Module’s “Implied Readability” Technique.

  • Use same Tester module to test this application.

Same output for this application too.

Here we are using just few modules. However, it is not the same case in Real-time projects. A Real-time Module may depend on more Modules and it is not the right approach to import all of them. Am I right??

Few Important Points to Remember

In this section, we will briefly discuss about some important points to remember about Java 9 Module System.

  • Every Module, by definition reads itself.
  • Java 9 Module System does NOT supoort Cyclic Graphs that means it supports only Acyclic Graphs.
  • Two or more Modules may have same package names. That means we can use same package names in two different Modules.
  • By default, all Java 9 Modules (JDK Modules or User Define Modules) depends on “java.base” Module.

That’s it all about “Develop and Test Implied Dependency With Eclipse IDE” topic. We will discuss some more concepts about Java SE 9 Modules Development in my coming posts.

Please drop me a comment if you like my post or have any issues/suggestions/type errors.

Thank you for reading my tutorials.

Happy Java SE 9 Learning!

By admin

Leave a Reply

%d bloggers like this: