Java Platform Module System (Project JIGSAW) - Part-1 Introduction

Why Project Jigsaw

Project JIGSAW is a star project of Oracle corporation and is responsible for release of Java Platform Module system. Modularity means breaking coarse grained JDK/JARS into fine grained modules to reduce coupling, provide stronger encapsulation and move from monolithic code and data to self-describing collection of code and data.

According to Mark Reinhold following problems necessitated new module system and JAVA 9, will address all of them.

1.Classpath Limitations 

2. Bulky monolithic JDK 

3. Poor Encapsulation 

Limitations of Classpath

JAR Hell, a common term which defines ways in which classloading process can end up not working.Classpath causes following well-known problems:

• If two jars has different names but same content, it will result in a conflict during classloading. What's worse is that it's hard to find conflict

• Fundamental issue with jar files is that they are not components. Rather they are containers that will be searched linearly during classloading.Classpath is a way to look up for classes regardless of what components they're in, or what packages they intended to use

Bulky monolithic JDK

Big size of monolithic JDK causes following problems:

• Doesn't fix on small devices. Even IoT type devices fall short of memory to hold all JDK.What's bad is that not all part of it is used by application

• It causes issues with CLOUD. CLOUD is all about optimising use of hardware, but running thousand of images of whole JDK when only tiny part of is used in application, is only a waste

Poor Encapsulation

public is too public ! Consider the following classes (assume both are public): com.school.StudentDao com.school.impl.StudentDaoImpl

Suppose in a class my team should use only studentDao not and not studentDaoImpl directly. However there is no way to enforce that on classpath.

Given the above classes, someone could still do this in Java 8:

Class c = Class.forName("com.school.impl.StudentDaoImpl");

Object obj = c.getConstructor().newInstance();

Module System : Solution to problems

A module is a self describing collection of data and code.It comprises of set of packages, containing Java Classes, interfaces, resources and a module-info.java file which is called module descriptor. 

Every module has only one module-info.java which contains information of 

  -What other modules this particular module is dependent(requires)

 - Which of the packages present in this module is exposed to others modules(exports) 

Unlike the class-path mechanism , which look for all classes at classpath, module system ensures that, a module can only refer to types(data) in the module upon with it depends. This access-control mechanism of Java language and JVM prevents code from accessing types in packages that are not exported by their defining modules.

When code in a particular module refers to a type in a package, then that packages is guaranteed to be defined either in same module or in exactly one of the modules read by another module(which exports that package and current modules requires it). When looking for the definition of a specific type there is, therefore, no need to search for it in multiple modules, or worse, along the entire classpath.

This mechanism not only solves classical classpath conflict, but also makes classloading more reliable, modular, faster and improves running performance.

Moreover, breaking monolithic JDK into smaller chunks and exporting only those modules which are actually used, not only makes application smaller, it results in better utilisation of hardware and enhances system performance.

Java Enhancement Proposal(JEP) for Jigsaw

Project Jigsaw is an enormous and prestigious project and is ongoing for quite few years.Following JEP's were assigned to Jigsaw :

The Modular JDK (JEP 200): 

   -Break big monolithic JDK into several smaller modules

The Modular Source Code  (JEP 201): 

   -Reorganise JDK source code to modules and break fat jars like rt.jar into lightweight modules

The Modular Run Time Code  (JEP 220): 

   -Restructure JDK and JRE run-time images to accomodate modules and to improve performace,          security and maintainability

Encapsulate Most Internal APIs (JEP 260): 

   -Make most of JDK's most internal APIs inaccessible by default but leave a few critical,widely- used internal API's accessible until replacement exists for all

Modular System (JEP 261): 

   -Functionality to provide user to write their own modules

The Java Linker : jlink (JEP 282):

   -Create a tool to assemble and optimize a set of modules and their dependencies into a custom run-time images 

Dive into Modular System

Jdk-8 Vs Jdk-9

Pre JDK-9 , JDK folder used to have jre folder and two fat jars (rt.jar and tools.jar). 

JDK-9 has removed jre folder along with tools.jar file and added a new folder jmods.

This jmods folder has 97 modules(java 9 EA release) and can be found at ${JAVA_HOME}/jmods.

More number of modules might get added in future release by Orcale corp.

Java 9 Module System

Oracle has divided all jars of JDK-9 into two parts :

• All JDK jars has been moved to JDK modules and their names starts with "jdk."

• All Java SE jars names starts with "java."

• "java.base" is called as base module. This module isn't dependent on any other module.All other modules, by default, depends upon this base module.

Difference between Java 8 packages and Java 9 modules

Packages are top level components in java-8 and earlier versions.A package contains following items:

• Code(Interfaces, Classes, Abstract classes etc.
• Data
• Resources

1. XML
2. Resources
3. Static files
4. Properties files etc.

Module is a top level component in java-9 and contains one or more packages along with a descriptor file called "module-info.java", that is always placed at top level and it defines rules for exporting packages and reading other modules.

In nutshell, module system is a superset of package system that was there pre-java 9, with an additional module descriptor file.

Module Descriptors

Each Java module has a single module descriptor , i.e. module-info.java file. This file defines which packages of current module will be exported and on what other modules it is dependent upon.
Following are the options available for descriptors :

• requires <module-name>

         Requires Comamnd is used to define on what modules this current module is dependent upon

• requires transitive  <module-name>

        Transitive keyword is used when current module is dependent upon modules that are required   by the module it is dependent upon. E.g. if module A depends upon B, B depends upon C, then with transitive keyword, we mean A reads C as well. Even though A read B directly.

     
         Note : By default transitive dependencies aren't resolved.

• requires static  <module-name>

        This dependency check is mandatory at compile time and is optional at runtime.

• exports <package-name>

         This package is exported to all modules. If a package is not exported it cannot be used by any  other modules and can only be used by packages in the same module.

• exports <package-name> to <module-name>

        This package is exported to this specific module and not to all modules. 

• exports <package-name> to <module-name>

        This package is exported to this specific module and not to all modules.

• opens <package-name>

        If a module doesn't export a package then it cannot be accessed by any module.With                         "opens"keyword, all modules can access this package through Reflection.Access of public type is present at compile type and private type at runtime.

• Uses <service-interface> 

        Implementation of interfaces in this module can reside in this module or in some other module

• Provides <service-interface> with <class1>,<class2>

        Implementation is mentioned for this interface.

That's all for Part-1 Introduction. In part-2 i will discuss in depth, creation of custom modules and other concepts of Java Module system. 

Happy Learning!!