Introduction to Java 9 Modularity and Jigsaw Project

How do you think about Module?

As lines of code? As bits and bytes? UML diagrams? Maven POMs?

A code base consists of modules communicating with each other. Each module has three basic properties: a name, dependencies on other modules, and features it provides to others.

Lets understand with example of Cab Booking System

In Cab Booking System, We have different modules like Cab, User, Driver and Geo Map. Let’s take a Cab module, Inorder to complete Cab booking it needs to call login and route service to get user and route details. Again we have all three properties:

  • Name of Module – Cab module
  • Depends on – login and route service
  • Feature it Provides – Cab Booking

Have you noticed that every modules having dependencies on other modules and having some features which other module can use it.

Cab Booking System
Cab Booking System

Systems built from such modules are more controlled to changes and, depending on how dependencies are realized, more flexible at launch and maybe even run time. And this is what modularity is all about.

Java 9 introduced modular system design with help of Jigsaw project.

Introduction to Jigsaw Project

Jigsaw Project is new features introduced by Oracle corporation in Java 9 to enable modularity.

Project was started to be part of Java SE 7, However due to hudge changes it was postponed to Java 8 and again postponed to Java 9.

Primary Goal of the Jigsaw project: The module system should be powerful enough to modularize the JDK and other large legacy code bases, yet still be approachable by all developers.

Objective of Jigsaw Project
  1. Make the Java SE Platform, and the JDK, more easily scalable down to small computing devices.
  2. Improve the security and maintainability of Java SE Platform Implementations in general, and the JDK in particular.
  3. Enable improved application performance.
  4. Make it easier for developers to construct and maintain libraries and large applications, for both the Java SE and EE Platforms.

Downside of Current System

Java is lacking the concepts to properly support modularity across artifacts.

Let’s discuss some of problems about current system.

  1. 1. Unexpressed dependencies

    We all are come across exception like NoClassDefFoundError, It occurs when JVM can not find a class on which code depends that is currently being executed. Withing JAVA SE platform we do not have dependencies handler, To accomplish the task, we use to have third-party dependencies tools like Maven and Gradle.

  2. 2. Shadowing

    Sometimes different JARs on the class path contain classes with the same fully-qualified name. Since a class will be loaded from the first JAR on the class path that contains it, that variant will shadow all others and make them unavailable. It will leads to a problem when if there are two different version of libraries are present in class path and latest version have removed some of methods from it.

  3. 3. Version Conflicts

    Version conflicts arise when two required libraries depend on different, non-compatible versions of a third library. If both versions are present on the class path, the behavior will be unpredictable.

    Build tools are generally able to detect this scenario. They may warn about it and usually resolve it with simple mechanisms like picking the most current version.

  4. 4. Weak Encapsulation

    Java’s visibility modifiers are great to implement encapsulation between classes in the same package. But across package boundaries there is only one visibility for types: public

    If class is declared as a public then its visible to outside of the jar too, These leads to accessing some of Internal Critical APIs like sun.*, *.internal.* etc.

    The most notorious example is sun.misc.Unsafe; a JDK-internal class that let’s us do crazy things (by Java standards) like directly allocating and freeing memory. Many critical Java libraries and frameworks like Netty, PowerMock, Neo4J, Apache Hadoop, and Hazelcast use it.

  5. 5. Security

    As we have seen weak encapsulation in above topic, Which leads to some critical functionalities will be exposed to all code running in the same environment. This means that malicious code can access critical functionality.

  6. 6. Rigid Java Runtime

    Before Java 8 there was no way to install a subset of the JRE. All Java installations had support for, e.g., XML, SQL and Swing, which many use cases do not require at all.

    While this may be of little relevance for medium sized computing devices (e.g. desktop PCs or laptops) it is obviously important for the smallest devices like routers, TV-boxes, cars where Java is used. where reducing an image’s footprint will reduce costs.

What is Java 9 Module

A Module is a self-describing collection of Code, Data and some Resources. It is a set of related Packages, Types (classes, abstract classes, interfaces etc) with Code & Data and Resources. they are a container for types and resources; but unlike JARs, they have additional characteristics—these are the most fundamental ones:

  • A name, preferably one that is globally unique.
  • Declarations of dependencies on other modules.
  • A clearly defined API that consists of exported packages.

Java 9 Module System Diagram

As of now, Java 9 Module System has 95 modules in Early Access JDK. Oracle Corp. has separated JDK jars and Java SE Specifications into two set of Modules.

  • All JDK Modules starts with jdk.*
  • All Java SE Specifications Modules starts with java.*

Java 9 Module System has a java.base Module. It’s known as Base Module. It’s an Independent module and does NOT dependent on any other modules. By default, all other Modules dependent on this module.

Difference in Application Structure between Java 8 and Java 9

Till Java 8 we do not have much changes in structure of the application. Every project contains Packages, Classes and Resources.

Java 8 Application Structure
Java 8 Application Structure

In Java 8 we have package as top most element which groups set of same types in a group. It also contains resources like XML and Properties.

Java 9 has almost same structure as Java 8 except they have introduced one more layer called Module, which is used to group a set of related Packages into a group. And one more new component that Module Descriptor module-info.java. Rest of the structure is same as Java 8.

Java 9 Application Structure
Java 9 Application Structure

Java 9 Module System is not supporting sub module within the main module, Each module having only one module and module descriptor.

Inshort Java 9 Module have following Components.

  • Module Descriptor
  • Set of Packages
  • Set of Types and Resources

That’s it for Java 9 Module System, We also have article on steps to setup Eclipse IDE for Java 9 and create first Java 9 module.

Hope you enjoy the article. Please drop us a comments if you like our article or have any suggestions/issues.

Thank you for reading our tutorials.

Happy Learning 🙂 !!

It's good to share...Share on FacebookTweet about this on TwitterShare on LinkedInPin on PinterestShare on Google+Email this to someone

Leave a Reply

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