Java Classloader

The Java Class Loader is a part of the Java Runtime Environment that dynamically loads Java classes into the Java Virtual Machine.[1] Usually classes are only loaded on demand. The Java run time system does not need to know about files and file systems as this is delegated to the classloader.

A software library is a collection of related object code. In the Java language, libraries are typically packaged in JAR files. Libraries can contain objects of different types. The most important type of object contained in a Jar file is a Java class. A class can be thought of as a named unit of code. The class loader is responsible for locating libraries, reading their contents, and loading the classes contained within the libraries. This loading is typically done "on demand", in that it does not occur until the class is called by the program. A class with a given name can only be loaded once by a given classloader.

Each Java class must be loaded by a class loader.[2] Furthermore, Java programs may make use of external libraries (that is, libraries written and provided by someone other than the author of the program) or they may be composed, at least in part, of a number of libraries.

When the JVM is started, three class loaders are used:[3][4]

  1. Bootstrap class loader
  2. Extensions class loader
  3. System class loader

The bootstrap class loader loads the core Java libraries[fn 1] located in the <JAVA_HOME>/jre/lib directory. This class loader, which is part of the core JVM, is written in native code.

The extensions class loader loads the code in the extensions directories (<JAVA_HOME>/jre/lib/ext,[3] or any other directory specified by the java.ext.dirs system property). It is implemented by the sun.misc.Launcher$ExtClassLoader class.

The system class loader loads code found on java.class.path, which maps to the CLASSPATH environment variable. This is implemented by the sun.misc.Launcher$AppClassLoader class.

User-defined class loaders

The Java class loader is written in Java. It is therefore possible to create your own class loader without understanding the finer details of the Java Virtual Machine. Every Java class loader has a parent class loader, 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[5]).
  • 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 classloaders, isolating the application from other applications, but sharing classes between deployed modules. So-called "servlet containers" are typically implemented in terms of multiple classloaders.[2][6]

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.[7] 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 classloader.
  • 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" classloader, but instead may be composed of several (potentially very many) nested, cooperating classloaders. Classes loaded by different classloaders may interact in complex ways not fully comprehended by a developer, leading to errors or bugs that are difficult to analyze, explain, and resolve.[8]

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.

To remedy the JAR hell problems, a Java Community Process — JSR 277 was initiated in 2005. The resolution — Java Platform Module System — intended to introduce a new distribution format, a modules versioning scheme, and a common modules repository (similar in purpose to Microsoft .NET's Global Assembly Cache). In December 2008, Sun announced that JSR 277 was put on hold.[9] The Java Module System was later rebooted as "project Jigsaw"[10] which was included in Java 9.

See also

Footnotes
  1. These libraries are stored in Jar files called rt.jar, core.jar, server.jar, etc.

References
  1. Mcmanis, Chuck (October 1, 1996). "The basics of Java class loaders". JavaWorld. Retrieved 2020-07-13.
  2. Christudas, Binildas (January 26, 2005). "Internals of Java Class Loading". onjava.com. Archived from the original on 2018-05-10.
  3. "Understanding Extension Class Loading". The Java Tutorials. docs.oracle.com. Retrieved 2020-07-13.
  4. Sosnoski, Dennis (April 29, 2003). "Classes and class loading". IBM DeveloperWorks. Retrieved 2008-01-26.
  5. Roubtsov, Vladimir (May 9, 2003). "Cracking Java byte-code encryption". JavaWorld. Retrieved 2020-07-13.
  6. deBoer, Tim; Karasiuk, Gary (August 21, 2002). "J2EE Class Loading Demystified". IBM DeveloperWorks. Retrieved 2008-01-26.
  7. https://web.archive.org/web/20130601002059/http://incubator.apache.org/depot/version/jar-hell.html
  8. http://articles.qos.ch/classloader.html
  9. Mark Reinhold (September 20, 2010). "Project Jigsaw". Oracle Corporation. Archived from the original on 2015-12-08.
  10. "Project Jigsaw". Oracle Corporation. Retrieved 2015-11-29.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.