The monolithic nature of the JDK

Java has continually evolved in an impressive fashion since 1995 and with each evolutionary step, the JDK grew larger. As with Java 8, the JDK had become prohibitively large. Prior to Java 9, there were several problematic issues stemming from the monolithic nature of the JDK, including:

• Because the JDK is so large, it does not fit on very small devices. In some development sectors this is enough reason to find a non-Java solution for software engineering problems.
• The oversized JDK resulted in waste. It was wasteful in terms of processing and memory when running on devices, networks, and the cloud. This stems from the fact that the entire JDK is loaded, even when only a small subset of the JDK is required.
• While the Java platform has great performance when running, the startup performance, in terms of load and launch times, leaves much to be desired.
• The vast number of internal APIs has also been a pain point. Because so many internal APIs existed and were used by developers, the system has been difficult to evolve.
• The existence of internal APIs has made it difficult to make the JDK secure and scalable. With so many internal dependencies, isolating security and scalability issues has been overly problematic.

The answer to the monolithic woes of the JDK is the module. Java 9 introduced the module and its own modular system. One of the great updates to the platform is that only the modules needed are compiled, as opposed to the entire JDK. This modular system is covered throughout this book.