In this chapter, the reasoning behind the FatJAR packaging style is explained. The road leading to FatJAR packaging is explained, as are the advantages and disadvantages of a FatJAR solution. In the world of Java EE Microservices, both pure Java EE and additionally Spring Framework is represented by a set of libraries. Even though Java EE gives us an option of separating the code and dependent libraries, in the end, both the API and the libraries with implementations contained inside are required for the application to run. In the previous era of Application servers, the APIs and their implementations were already contained within the application server. The applications deployed onto the application server did not carry such libraries inside. Those dependencies were provided by the application server as a runtime environment for the application. In fact, most modern application servers do not load all the libraries at startup, but leverage dynamic loading to create a rightsized environment that is a perfect fit for the application running on it, which also results in resource savings.
For historical reasons, an application server usually hosted more than one application. The process of extracting shared libraries into a common place led to various optimizations:
- Persistent storage space savings
- Memory savings
- Application-size shrinks
- Deployment time is reduced
A first observation is simple: the library only has to be distributed once. This paradigm is used across many fields in computer science and is generally considered a good practice. Linux package managers serve as a perfect example. Many user-space programs rely on the same libraries. Those are only downloaded once and are shared by all other dependent deployables.
Memory savings follow the same principle. When one or more deployment units require the same library, there is a possibility of only loading such a library into memory once. A common enhancement practiced by almost every application server is only to load the libraries truly required by applications deployed to a fast, nonpersistent memory. Dozens, or even hundreds, of applications, could be deployed onto a single application server. In general, if the number of applications deployed is more than one, cost savings occur by sharing a common library.
As a result, the size of the deployment unit containing the application, usually in the form of a Java Web Archive, is significantly lower. The application is only compiled against Java EE APIs. The Java EE APIs are only required during the process of compilation and are not included in the deployment unit. When no special third-party libraries were used, the deployment unit archive contained only classes with business logic and nothing more. The resulting size was in units of kilobytes. Not more. Naturally, when an application is deployed into an application server, the classloader, which happens to be specific to each application server, loads all the classes included in the deployment unit. Assuming loading a single class has a fixed computational complexity of O(n), loading k classes results in a computational complexity of O(k*n). In other words, the time required to load classes grows linearly with the number of classes included. Having the number of libraries loaded with each deployment reduced from potentially hundreds of megabytes to a few kilobytes significantly reduces the deployment time, usually down to dozens of milliseconds in the case of small changes.
With Microservices, each instance of a service exists in an isolated environment. Therefore, the situation with one application server having n > 1 applications deployed becomes obsolete. Each Microservice is packaged and scaled independently, with dedicated resources allocated for each instance, preventing resource sharing in ways an old-fashioned application server used to do.
Discarding the concept of separation of runtime dependencies and business logic represents a significant simplification. In the Java world, a self-sufficient JAR with all runtime dependencies packaged into one package is known as FatJAR. Often, alternative names, such as UberJAR, are used.