The JAR and WAR files mostly do not come with a complete set of libraries required for code to run. In practice, programs rely on common libraries. In Java, the standard library is a perfect example. Java programs rely on the standard library to operate. Packages beginning with java.*, such as java.io or java.lang, are part of the standard library and are not bundled with the application. The separated distribution of common libraries is a general concept practiced for decades. Package managers in Linux operating systems only load shared libraries for each program once. When a program is installed, the package manager iterates over libraries required for the installed application to be present on the system and only download the missing ones. This way, the computer's persistent storage is not easily bloated with many instances of the same library. The same principle is applied in the Java world. If every Java application, including Microservices, depends on the standard library, there is no reason to distribute the standard library with the application, but instead install it once on the system Java applications are expected to run. This makes the Java-based application archives much smaller and faster to distribute. 

The principle of the class loaders hierarchy in Java reflects the pattern of shared or common dependencies. Class loaders are special classes dedicated to loading the resources required for a Java application to run, including the application classes. There are more types of class loaders, each type being represented by one or more classes, as shown here:

Different classloaders load different parts of code from different places. There is no inheritance among classloaders, only delegation. The structure is represented by a directed acyclic graph. The principle of class loaders can be summed up in the following statements:

• Different resources are loaded by different class loaders.
• Different class loaders are invoked at different times.
• One type of class loader may be invoked zero or multiple times.

The bootstrap, also called the primordial, class loader is not distributed with the application. As the Java standard library is distributed as a separate package, the bootstrap class loader is also part of the Java Runtime Environment package. Other class loaders may be distributed with an application server or servlet container; some may even be part of the final application, if required.

The principle of shared dependencies can be generalized even further. Another place where sharing libraries is a big concern is memory management. For any program to be executed, it is first loaded from persistent storage into a significantly faster memory, nowadays usually a RAM. Different components of each application are loaded on demand, so-called lazily, that is loaded only when required. It is common for two or more applications to require the same library to be loaded in memory, and it is a common feature of the operating system's memory management to load the library only once. Unlike in the case of persistent storage, volatile memory is much more limited in space. As the operating system loads common libraries only once, the goal is for the Java runtime only to load the same libraries once.

Next, we will discuss fat packages and the creation of fat JAR.