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 the following ones:

  • Because the JDK was so large, it did 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 stemmed from the fact that the entire JDK was loaded, even when only a small subset of the JDK was required. 
  • While the Java platform had great performance when running, the startup performance, in terms of load and launch times, left much to be desired. 
  • The vast number of internal APIs was also a pain point. Because so many internal APIs existed and were used by developers, the system was difficult to evolve. 
  • The existence of internal APIs made it difficult to make the JDK secure and scalable. With so many internal dependencies, isolating security and scalability issue was 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.

Modules solve the pre-Java 9 JDK monolithic issue by providing strong encapsulation.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset