In Chapter 1, Introducing Java 9 Modularity, we examined the large size of the JDK, both in terms of the file size of rt.jar as well as the number of classes that are bundled in it. Typically, you wouldn't think about the JDK when developing Java applications. Once you've installed the JDK on your development machine, it sits in a remote corner of your hard disk at $JAVA_HOME and it doesn't bother you. There are, however, a few instances where you would need to worry about the size of the JDK, especially when bundling an application executable. Here are a couple of such occasions:

• Runtime bundles for embedded devices: Java has been known to run on portable and embedded devices, such as compact music players, microwaves, and washing machines. Many of these are devices with scarce hardware capacities for memory and processing power, and for Java to run on those devices, the runtime should obviously be a part of the installed application. The size of the Java SE runtime is so prohibitive that there is a separate platform (Java ME) for such scenarios.
• Runtime images for microservices: A common trend in recent years is to deploy lightweight microservices in the cloud. Instead of having one centralized web application that does everything, the application is split into separate smaller services that run on different machine instances and communicate with each other over the network. The runtime image for each instance is a self-sufficient set of binaries that include the application classes and the Java runtime. These microservices are ideally stateless, scalable, and disposable, so they'd ideally need to be lightweight and performant. Bundling a 75 MB runtime that needs to be a part of every instance doesn't really help.

Think for a minute about why this problem even exists. Well, it's because of the classpath model of previous versions of Java. Any piece of code can potentially refer to any other Java type in the classpath, and there's no saying what's required and what's not, so we had no choice but to add the whole platform.

This is no longer the case with modular programming! We've seen that with module resolution, given a starting point, we can precisely identify which modules are required for its execution. This applies equally to both application and platform modules, since they both follow the same contract. Thanks to this, we can now apply the module resolution process and come up with a unique bare minimum set of platform and application modules that you'd need to run any application. Thus, when distributing an application with runtime, for example, you don't have to include the entire platform. Instead, you just include the platform modules that are necessary, and we do just that by introducing a whole new step in Java application development that we didn't have before--linking.