To run a small or big application, a runtime environment up to Java 8 is required because JDK is built to support monolithic design. All libraries are tightly coupled with each other and for deployment full JDK is required.

Maintainability: We all want an application to be loosely coupled, highly united, readable, and understandable. So we are using classes and packages. Day by day Java is growing exponentially in terms of size and packages to provide better features, but dependencies between packages is compromised. So we need something new that is better than packages for maintaining our code base.

JAR Hell: Before Java 9,  The JVM does not have thought that how JAR on the class path depends on another Jar. It essentially loads a bunch of JARs, but it does not validate their dependencies. The JVM breaks the execution at runtime when a JAR is missing. The JARs don't characterize accessibility constraints such as open or private. The whole substance of all JARs on the class path is totally visible to all the other JARs from the class path. There is no way to declare that a few classes in a JAR are private. All classes and methods are open related to the class path. Sometimes, we have jar files that contain multiple versions of a single class. The Java ClassLoader loads only one version of this class, and it does not determined which one. This creates uncertainty about how our program is  going to work. This issue is known as JAR Hell. The Module Path concept presented in Java 9 tends to illuminate issues caused by the class path.

Implicit Dependency: We have all seen the NoClassDefFoundError error a few times. It comes when JVM is not able to discover a class on which code it is executing. Finding depending code and lost dependency is simple, but dependency that is not in classLoader is troublesome to recognize, since there are chances that the same class is stacked by numerous class loaders. The current JAR framework is not able to express which other JAR file is dependent, so that JVM understands and resolves dependency.

Lack of strong encapsulation: Java's visibility modifier provides strong encapsulation between classes of the same packages. Current Java encapsulation works with ClassPath where every public class is visible to other classes because several critical JDK API classes are open for other classes.

All preceding issues are fixed with Java 9 module concepts.