This is a continuation of the module system introduced to Java 9 . You can find Part — I at the link below:
The module system comes with its on set of rules on how it can be accessed. The module should be allowed to access the other module via the requires keyword. The other module should export the package and the type itself should be public (to make it visible)
The module system also requires that two modules cannot have the same package name. This enforcement separates the module-path from the class-path paradigm where packages could be overridden by multiple jars having same package name. …
Java 9 as we all know introduced the Java Platform Module System (JSR 376). This addresses some of the issues of the existing Java ecosystem.
The three main issues from a development point of view that the module system in Java 9 tries to address:
So then how does the module system promise all this? To answer the question we should first understand Java’s module system.
A traditional java application involves building libraries into jars and placing them on the class-path of the run-time. The run-time resolves the dependencies for the types using the the package name. Once in the class-path, the JVM treats classes in a JAR no differently from separate class files all in the same root directory. At run-time, as far as the JVM is concerned, an application is just a set of classes in a flat list of packages. …