Java class loader: Difference between revisions

Revision as of 14:03, 27 April 2012

Latest revision as of 18:15, 26 November 2024

(111 intermediate revisions by 74 users not shown)

Line 1:

The '''Java Classloaderclass loader''' is a, part of the [[Java Runtime Environment]] that dynamically, [[LoaderDynamic (computing)loading|loaddynamically loads]]s [[Java class]]es into the [[Java virtual machine|Java Virtual Machine]].<ref>{{cite web

|last1=Mcmanis |first1=Chuck

|url=http://www.javaworld.com/javaworld/jw-10-1996/jw-10-indepth.html

|date=1996-10-01 |df=mdy

|title=The basics of Java class loaders

|url=https://www.infoworld.com/article/2077260/learn-java-the-basics-of-java-class-loaders.html

|publisher=[[JavaWorld]]

|title=The basics of Java class loaders

|first=Chuck |last=Mcmanis

|work=[[JavaWorld]]

|date=1996-10-01

|accessdate=2020-07-13

|accessdate=2008-01-26 }}</ref> Usually classes are only loaded [[lazy initialization|on demand]]. The Java run time system does not need to know about files and file systems because of class loaders. [[Delegation (programming)|Delegation]] is an important concept to understand when learning about class loaders.

}}</ref> Usually classes are only loaded [[lazy initialization|on demand]]. The virtual machine will only load the class files required for executing the program.{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}} The Java run time system does not need to know about files and file systems as this is [[Delegation _(object-oriented_programming)|delegated]] to the class loader.

A [[Library (computing)|software library]] is a collection of related [[object code]].

In the [[Java (programming language)|Java language]], libraries are typically packaged in [[jar-JAR (file format)|JarJAR 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 actually usedcalled by the program. A class with a given name can only be loaded once by a given classloaderclass loader.

Each Java class must be loaded by a class loader.{{sfn | Horstmann | 2022 | loc=§8.2.5 Writing Byte Codes to Memory}}<ref name="Christudas">{{cite web

|last1=Christudas |first1=Binildas

|url=http://www.onjava.com/pub/a/onjava/2005/01/26/classloading.html

|date=2005-01-26 |df=mdy

|title=Internals of Java Class Loading

|url=http://www.onjava.com/pub/a/onjava/2005/01/26/classloading.html

|publisher=onjava.com

|title=Internals of Java Class Loading

|first=Binildas |last=Christudas

|archiveurl=https://web.archive.org/web/20180510223447/http://www.onjava.com/pub/a/onjava/2005/01/26/classloading.html

|date=2005-01-26

|archivedate=2018-05-10

|accessdate=2009-10-02 }}</ref> Furthermore, [[Java (software platform)|Java]] programs may make use of [[Library (computing)|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.

|work=onjava.com

}}</ref> Furthermore, [[Java (software platform)|Java]] programs may make use of [[Library (computing)|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:<ref name="TJT:UECL">{{cite web

|url=httphttps://javadocs.sunoracle.com/docs/booksjavase/tutorial/ext/basics/load.html

|title=Understanding Extension Class Loading

|department=The Java Tutorials

|publisher=java.sun.com

|work=docs.oracle.com

|date=2008-02-14

|accessdate=20092020-1207-08 13
}}</ref><ref>{{cite web

|last1=Sosnoski |first1=Dennis

|url=http://www.ibm.com/developerworks/java/library/j-dyn0429/

|date=2003-04-29 |df=mdy

|title=Classes and class loading

|url=http://www.ibm.com/developerworks/java/library/j-dyn0429/

|publisher=ibm.com

|title=Classes and class loading

|first=Dennis |last=Sosnoski

|work=IBM DeveloperWorks

|date=2003-04-29

|accessdate=2008-01-26 }}</ref>:

}}</ref>{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}}

# Bootstrap class loader

# Extensions class loader

# System class loader

The bootstrap class loader loads the core Java libraries<ref group=fn>These libraries are stored in [[JAR (file format)|Jar files]] called ''rt.jar'', ''core.jar'', ''server.jar'', etc.</ref> (located in the <code><JAVA_HOME>/jre/lib</code> directory(or <code><JAVA_HOME>/jmods></code> for Java 9 and above) directory. This class loader, which is part of the core JVM, is written in native code. The bootstrap class loader is not associated with any {{java|ClassLoader}} object.{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}} For instance, {{java|StringBuilder.class.getClassLoader()}} returns {{java|null}}.{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}}

The extensions class loader loads the code in the extensions directories (<code><JAVA_HOME>/jre/lib/ext</code>,<ref name="TJT:UECL"/> or any other directory specified

by the <code>java.ext.dirs</code> system property). It is implemented by the <code>sun.misc.Launcher$ExtClassLoader</code> class.

The system class loader loads code found on <code>java.class.path</code>, which maps to the system <code>[[Classpath (Java)|CLASSPATH]]</code> [[environment variable. This is implemented by the <code>sun.misc.Launcher$AppClassLoader</code> class]].

==User-defined class loaders==

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.{{sfn | Horstmann | 2022 | loc=10.1.2 The Class Loader Hierarchy}} The parent class loader is defined when a new class loader is instantiated or set to the virtual machine's system default class loader.

By default, all user classes are loaded by the default system class loader, but it is possible to replace it by a user and even to chain class loaders as desired.{{Clarify|date=January 2011}}

This makes it possible (for example):

* to load or unload classes at runtime (for example to load libraries dynamically at runtime, even from aan [[Hypertext Transfer Protocol|HTTP]] resource). This is an important feature for:

** implementing scripting languages, such as [[Jython]]

** using [[JavaBean|bean]] builders,

** allowing user-defined [[extensibility]]

** allowing multiple [[Namespace (computer science)|namespace]]s to communicate. This is one of the foundations of [[Common Object Request Broker Architecture|CORBA]] / [[Java remote method invocation|RMI]] protocols, for example.

* to change the way the [[Java bytecode|bytecode]] is loaded (for example, it is possible to use [[Encryption|encrypted]] Java class bytecode<ref>{{cite web

|last1=Roubtsov |first1=Vladimir

|url=http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html?page=1

|date=2003-05-09 |df=mdy

|title=Cracking Java byte-code encryption

|url=https://www.infoworld.com/article/2077342/cracking-java-byte-code-encryption.html

|publisher=javaworld.com

|title=Cracking Java byte-code encryption

|first=Vladimir |last=Roubtsov

|work=[[JavaWorld]]

|date=2003-05-09

|accessdate=20082020-0107-26 13
}}</ref>).

* to modify the loaded bytecode (for example, for load-time [[Aspectaspect weaver|weaving]] of aspects when using [[aspect-oriented programming]]).

== Class Loadersloaders in JEEJakarta EE ==

[[Jakarta EE]] (formerly Java EE and J2EE) application servers typically load classes from a deployed [[WAR (file format)|WAR]] or [[EAR (file format)|EAR]] archive by a tree of class loaders, isolating the application from other applications, but sharing classes between deployed modules. So-called "[[servlet container]]s" are typically implemented in terms of multiple class loaders.<ref name="Christudas"/><ref>{{cite web

|last1=deBoer |first1=Tim

|last2=Karasiuk |first2=Gary

|date=2002-08-21 |df=mdy

|url=https://www.ibm.com/developerworks/websphere/library/techarticles/0112_deboer/deboer.html

|title=J2EE Class Loading Demystified

|work=IBM DeveloperWorks

|accessdate=2008-01-26

}}</ref>

== {{anchor|jarhell}} JAR hell ==

[[Java Platform, Enterprise Edition]] (JEE) application servers typically load classes from a deployed [[WAR (Sun file format)|WAR]] or [[EAR (file format)|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.<ref name="Christudas"/><ref>{{cite web

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.<ref>{{Cite web|url=http://incubator.apache.org/depot/version/jar-hell.html|archive-url = https://web.archive.org/web/20130601002059/http://incubator.apache.org/depot/version/jar-hell.html|archive-date = 2013-06-01|title = Depot - Apache Incubator}}</ref> Three ways JAR hell can occur are:

|url=http://www-128.ibm.com/developerworks/websphere/library/techarticles/0112_deboer/deboer.html

* 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.

|title=J2EE Class Loading Demystified

* 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.

|first1=Tim |last1=deBoer

* 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.<ref>{{Cite web|url=http://articles.qos.ch/classloader.html|title=Taxonomy of class loader problems with Jakarta Commons Logging}}</ref>

|first2=Gary |last2=Karasiuk

|publisher=ibm.com

|date=2002-08-21

|accessdate=2008-01-26 }}</ref>

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 file|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.

== JAR hell ==

[[Java version history#Java SE 9|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 ''[[Modular programming|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 (file format)|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.<ref>{{cite web|first1=Neil|last1=Bartlett|first2=Kai|last2=Hackbarth|title=Java 9, OSGi and the Future of Modularity (Part 1)

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.<ref>http://incubator.apache.org/depot/version/jar-hell.html</ref> Three ways JAR hell can occur are:

|url=https://www.infoq.com/articles/java9-osgi-future-modularity/#1|publisher=InfoQ|date=2016-09-22}}</ref>

==See also==

* The first case is when a developer or deployer of a Java application has accidentally made two different versions of a library available to the 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 see the application still behaving as though the old library is in use, which it may well be.

* Another version of the problem arises when two libraries (or a library and the application) require different versions of the same third library. If both versions of the third library use the same class names, there is no way to load both versions of the third library 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 inexplicable errors or bugs{{Citation needed|date=January 2011}}.

The [[OSGi]] Alliance specified (starting as JSR 8 in 1998) a modularity framework that solved JAR hell for current and future VMs in ME, SE, and EE that is widely adopted. Using metadata in the JAR [[manifest file|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 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.<ref>http://www.osgi.org/News/20081217</ref>

== See also ==

* [[Loader (computing)]]

* [[Dynamic loading]]

* [[DLL hell]]

* [[OSGi]]

* [[Classpath (Java)]]

* [[Apache Maven]], automated software build tool with dependency management

* [[Java Platform Module System]]

==Footnotes==

{{reflist|group=fn}}

==References==

{{reflist|2}}

== External links ==

* [[Chuck Mcmanis]], "[http://www.javaworld.com/jw-10-1996/jw-10-indepth.html The basics of Java class loaders]", 1996

* [[Brandon E. Taylor]], "[http://www.developer.com/java/other/article.php/2248831 Java Class Loading: The Basics]", 2003

* [[Jeff Hanson]], "[http://www.devx.com/Java/Article/31614 Take Control of Class Loading in Java]", 2006-06-01

* [[Andreas Schaefer]], "[http://www.onjava.com/pub/a/onjava/2003/11/12/classloader.html Inside Class Loaders]", 2003-11-12

* [[Sheng Liang]] and [[Gilad Bracha]], "[http://citeseer.ist.psu.edu/liang98dynamic.html Dynamic class loading in the Java virtual machine]", In Proceedings of the 13th ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA'98), ACM SIGPLAN Notices, vol. 33, no. 10, ACM Press, 1998, pp.&nbsp;36–44

<!-- dead link:

* [[Jeremy Whitlock]], "[http://dev2dev.bea.com/blog/jcscoobyrs/archive/2005/05/realworld_use_f.html Real-World Use For Custom ClassLoaders]", May 2005 -->

* Dr. Christoph G. Jung, "[http://www.roseindia.net/javatutorials/hotdeploy.shtml Classloaders Revisited Hotdeploy]", ''Java Specialist Newsletter'', 2001-06-07

* [[Don Schwarz]], "[http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html?page=1 Managing Component Dependencies Using ClassLoaders]", 2005-04-13

==External links==

[[Category:Java programming language]]

* Chuck McManis, "[https://www.infoworld.com/article/2077260/learn-java-the-basics-of-java-class-loaders.html The basics of Java class loaders]", 1996

[[Category:Java platform]]

* Brandon E. Taylor, "[http://www.developer.com/java/other/article.php/2248831 Java Class Loading: The Basics] {{Webarchive|url=https://web.archive.org/web/20201109091535/http://www.developer.com/java/other/article.php/2248831 |date=2020-11-09 }}", 2003

* {{cite book | last=Horstmann | first=Cay | title=Core Java | publisher=Oracle Press Java | date=April 15, 2022 | isbn=0-13-787107-4}}

* Jeff Hanson, "[http://www.devx.com/Java/Article/31614 Take Control of Class Loading in Java] {{Webarchive|url=https://web.archive.org/web/20201204030013/http://www.devx.com/Java/Article/31614 |date=2020-12-04 }}", 2006-06-01

* Andreas Schaefer, "[https://web.archive.org/web/20180506212821/http://www.onjava.com/pub/a/onjava/2003/11/12/classloader.html Inside Class Loaders]", 2003-11-12

* Sheng Liang and Gilad Bracha, "[https://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.762 Dynamic class loading in the Java virtual machine]", In Proceedings of the 13th ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA'98), ACM SIGPLAN Notices, vol. 33, no. 10, ACM Press, 1998, pp.&nbsp;36–44 {{doi|10.1145/286936.286945}}

* Jeremy Whitlock, "[https://web.archive.org/web/20080628071703/http://dev2dev.bea.com/blog/jcscoobyrs/archive/2005/05/realworld_use_f.html Real-World Use For Custom ClassLoaders]", May 2005

* Christoph G. Jung, "[https://web.archive.org/web/20130201093532/http://www.roseindia.net/javatutorials/hotdeploy.shtml Classloaders Revisited Hotdeploy]", ''Java Specialist Newsletter'', 2001-06-07

* Don Schwarz, "[https://web.archive.org/web/20180506083919/http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Managing Component Dependencies Using ClassLoaders]", 2005-04-13

[[Category:Java (programming language)]]

[[ar:محمل صف جافا]]

[[es:Java classloader]]

[[fr:Chargeur de classe Java]]

[[ja:Javaクラスローダー]]

[[uk:Java Classloader]]