Java class loader: Difference between revisions

Content deleted Content added
fix some broken refs and extlinks
Line 1:
The '''Java Class Loader''' is a part of the [[Java Runtime Environment]] that [[Dynamic loading|dynamically loads]] [[Java class]]es into the [[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
| publisherwork=[[JavaWorld]]
| date=1996-10-01
| accessdate=20152020-1107-2913
| 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 classloaders. [[Delegation _(object-oriented_programming)|Delegation]] is an important concept to understand when learning about classloaders.
 
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 (file format)|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.<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.
| publisherwork=onjava.com
| 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.
 
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>
# 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. 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 (<code><JAVA_HOME>/jre/lib/ext</code>,<ref>http name="TJT:UECL"//docs.oracle.com/javase/tutorial/ext/basics/load.html</ref> 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.
 
Line 51 ⟶ 56:
** allowing multiple [[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 Loaders in JavaJakarta EE ==
[[JavaJakarta Platform, Enterprise EditionEE]] (formerly Java EE and J2EE) 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 containerscontainer]]s" are typically implemented in terms of multiple classloaders.<ref name="Christudas"/><ref>{{cite web
 
|last1=deBoer |first1=Tim
[[Java Platform, Enterprise Edition]] (Java EE) 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
|last2=Karasiuk |first2=Gary
| url=https://www.ibm.com/developerworks/websphere/library/techarticles/0112_deboer/deboer.html
|date=2002-08-21 |df=mdy
| title=J2EE Class Loading Demystified
| url=https://www.ibm.com/developerworks/websphere/library/techarticles/0112_deboer/deboer.html
| first1=Tim |last1=deBoer
| title=J2EE Class Loading Demystified
| first2=Gary |last2=Karasiuk
|work=[[IBM DeveloperWorks]]
| publisher=ibm.com
| dateaccessdate=20022008-0801-2126
| accessdate=2008-01-26 }}</ref>
 
== {{anchor|jarhell}} 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.<ref>https://web.archive.org/web/20130601002059/http://incubator.apache.org/depot/version/jar-hell.html</ref> Three ways JAR hell can occur are:
 
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:
 
* 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.
Line 81 ⟶ 85:
 
To remedy the JAR hell problems, a [[Java Community Process]]&nbsp;— JSR 277 was initiated in 2005. The resolution&nbsp;— [[Java Platform Module System]]&nbsp;— 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>{{cite web
| url=https://blogs.oracle.com/mr/entry/jigsaw
| title=Project Jigsaw
| publisher=[[Oracle Corporation]]
| author=Mark Reinhold
| date=2010-09-20 |df=mdy
| archive-url=https://web.archive.org/web/20151208171951/https://blogs.oracle.com/mr/entry/jigsaw
| accessdate=2015-11-29
| archive-date=2015-12-08
| archive-url=https://web.archive.org/web/20151208171951/https://blogs.oracle.com/mr/entry/jigsaw
| url-status=dead
| archive-date=2015-12-08
| url-status=dead
}}</ref> The Java Module System was later rebooted as "project Jigsaw"<ref>{{cite web
| url=http://openjdk.java.net/projects/jigsaw/
| title=Project Jigsaw
| publisher=[[Oracle Corporation]]
| accessdate=2015-11-29
}}</ref> which was included in Java 9.
 
== See also ==
Line 103 ⟶ 107:
* [[Classpath (Java)]]
* [[Java Platform Module System]]
 
==Footnotes==
{{reflist|group=fn}}
 
==References==
{{reflist|2}}
 
== External links ==
* Chuck McManis, "[httphttps://www.javaworldinfoworld.com/jwarticle/2077260/learn-10java-1996/jwthe-basics-of-java-10class-indepthloaders.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, "[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, "[httphttps://citeseer.ist.psu.edu/liang98dynamicviewdoc/summary?doi=10.1.1.18.html762 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 -->
<!-- dead link:
* Dr. 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
* Jeremy Whitlock, "[http://dev2dev.bea.com/blog/jcscoobyrs/archive/2005/05/realworld_use_f.html Real-World Use For Custom ClassLoaders]", May 2005 -->
* Don Schwarz, "[https://web.archive.org/web/20180506083919/http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html?page=1 Managing Component Dependencies Using ClassLoaders]", 2005-04-13
* 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
 
<!--Categories-->
[[Category:Java (programming language)]]