Java class loader

The Java class loader is written in Java. It is therefore possible to create a custom class loader without understanding the finer details of the Java Virtual Machine. Apart from the Bootstrap class loader, every Java class loader has a parent class loader. The parent class loader is defined when a new class loader is instantiated or set to the virtual machine's system default class loader. This makes it possible (for example): • to load or unload classes at runtime (for example to load libraries dynamically at runtime, even from an HTTP resource). This is an important feature for: • implementing scripting languages, such as Jython • using bean builders • allowing user-defined extensibility • allowing multiple namespaces to communicate. This is one of the foundations of CORBA / RMI protocols for example. • to change the way the bytecode is loaded (for example, it is possible to use encrypted Java class bytecode). • to modify the loaded bytecode (for example, for load-time weaving of aspects when using aspect-oriented programming). == Class loaders in Jakarta EE ==

Jakarta EE (formerly Java EE and J2EE) application servers typically load classes from a deployed WAR or EAR archive by a tree of class loaders, isolating the application from other applications, but sharing classes between deployed modules. So-called "servlet containers" are typically implemented in terms of multiple class loaders. == JAR hell ==

JAR hell is a term similar to DLL hell used to describe all the various ways in which the classloading process can end up not working. Three ways JAR hell can occur are: • Accidental presence of two different versions of a library installed on a system. This will not be considered an error by the system. Rather, the system will load classes from one or the other library. Adding the new library to the list of available libraries instead of replacing it may result in the application still behaving as though the old library is in use, which it may well be. • Multiple libraries or applications require different versions of library foo. If versions of library foo use the same class names, there is no way to load the versions of library foo with the same class loader. • The most complex JAR hell problems arise in circumstances that take advantage of the full complexity of the classloading system. A Java program is not required to use only a single "flat" class loader, but instead may be composed of several (potentially very many) nested, cooperating class loaders. Classes loaded by different class loaders may interact in complex ways not fully comprehended by a developer, leading to errors or bugs that are difficult to analyze, explain, and resolve. The OSGi Alliance specified (starting as JSR 8 in 1998) a modularity framework that aims to solve JAR hell for current and future VMs in ME, SE, and EE that is widely adopted. Using metadata in the JAR manifest, JAR files (called bundles) are wired on a per-package basis. Bundles can export packages, import packages and keep packages private, providing the basic constructs of modularity and versioned dependency management. Java 9 introduced the Java Platform Module System in 2017. This specifies a distribution format for collections of Java code and associated resources. It also specifies a repository for storing these collections, or modules, and identifies how they can be discovered, loaded and checked for integrity. It includes features such as namespaces with the aim of fixing some of the shortcomings in the existing JAR format. The Java Platform Module System follows a different philosophy from the OSGi architecture that aims at providing modularity for the Java Runtime Environment in a backwards-compatible way that uses the default mechanism of loading classes that the JRE provides. However, since the Java Platform Module System does not offer the ability for controlled co-existence of libraries with different versions, it does not fully address the JAR hell problem.{{cite web|first1=Neil|last1=Bartlett|first2=Kai|last2=Hackbarth|title=Java 9, OSGi and the Future of Modularity (Part 1) ==See also==