The concept of JPMS i.e. Java Platform Module System came in Java 9. Its development was first started in 2005 and finally in 2017, this concept came under the project named Jigsaw.
Until Java 8, we used jar files for packaging and bundling the application, but from Java 9 onward, we will be using modules for that.
Modularity is the basic rule of good software engineering practices. This is a technique to tackle complexity of both design and maintenance of a software product. Java9 developers, took this recipe which finally changes the paradigm of programming.
In order to understand the difference between java 8 and 9, it is important to know the structure of our special configuration file which was introduced in Java 9 i.e. module-info.java. Please refer to this blog in order to get its in-depth knowledge.
Let’s compare the two discovering what exactly were the problems with using jar files and how they got eradicated with modular system.
NoClassDefFound Error :
This issue is found when JVM is unable to identify some .class files. While using Java8, there is no way to check all jar dependencies at the beginning only, so, if your application is missing some .class file, JVM will immediately return NoClassDefFound error in the middle of your program execution. However, in Java9, this check is made at the beginning only with the help of our configuration file known as module-info.java. If a dependent module is missing then JVM won’t start its execution. Hence, there will be no such error in the middle of your program execution.
Version Conflict :
Since Java 8 was using jar files, so their order in the class-path was important. Reason being, the JVM will always search the required .class file from left to right. If multiple jar files contain classes with the same fully-qualified name, there might be a chance of version conflict resulting in abnormal behavior. But in Java9, this problem can be resolved to some extent when you further group modules using layers. Layers are constructed at runtime and they have their own classloader. Thus, it should be absolutely possible to use modules in different versions within one application – they just need to go into different layers. You can have different layers that are isolated by different class loaders.
In the jar file, there is no mechanism to control the accessibility of packages to the outside world. Whatever was present in it is public to everyone. Any third party will be able to access any component resulting in security leakage. Java9, on the other hand, provided us with a beautiful feature of controlling the access of the packages to the outside world. This can be defined in the configuration file i.e. module-info.java. Hence, only the exported packages are visible to the other modules preventing security breaches.
Size of the application:
Jar files follow monolithic structure. Even to execute a simple program, asking us to print “Hello World!”, having size less than a KB may be, we need to maintain a large size with jars. This results into memory issues, decrement in terms of performance and many more. This major issue was handled brilliantly by Java9 by bringing up the idea of modules. Everything in today’s world is modularized beating the monolithic architecture. So in your application, you can specify only the required modules to run it, making it light weighted and suitable for small devices as well.
All the issues we just discussed about Java8 were popularly known as JAR HELL. Most of the problems got resolved in Java 9 by the special configuration file i.e. module-info.java.