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.
Have you noticed that every modules having dependencies on other modules and having some features which other module can use it.
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.
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.
Make the Java SE Platform, and the JDK, more easily scalable down to small computing devices.
Improve the security and maintainability of Java SE Platform Implementations in general, and the JDK in particular.
Java is lacking the concepts to properly support modularity across artifacts.
Let’s discuss some of problems about current system.
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.
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.
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.
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.
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.
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.
A name, preferably one that is globally unique.
Declarations of dependencies on other modules.
A clearly defined API that consists of exported packages.
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.
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.
Till Java 8 we do not have much changes in structure of the application. Every project contains Packages, Classes and Resources.
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 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.
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.