Java class loader: Difference between revisions

Revision as of 22:07, 28 June 2023

Latest revision as of 18:15, 26 November 2024

(12 intermediate revisions by 10 users not shown)

Line 1:

The '''Java Classclass Loaderloader''' is a, part of the [[Java Runtime Environment]] that, [[Dynamic loading|dynamically loads]] [[Java class]]es into the [[Java virtual machine|Java Virtual Machine]].<ref>{{cite web

|last1=Mcmanis |first1=Chuck

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

Line 32:

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

|title=Classes and class loading

|work=[[IBM DeveloperWorks]]

|accessdate=2008-01-26

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

Line 39:

# 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> (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 boostrapbootstrap class loader is not associated with any {{java|ClassLoader}} object.{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}} For instance, {{java|StringBuiliderStringBuilder.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

Line 47:

==User-defined class loaders==

The Java class loader is written in Java. It is therefore possible to create youra owncustom 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.

This makes it possible (for example):

Line 65:

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

== Class Loadersloaders in Jakarta 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

Line 72:

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

Line 84:

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.

}}</ref> which was included in [[Java version history#Java SE 9|Java 9]]. Releasedintroduced the [[Java Platform Module System]] in 2017,. itThis includesspecifies supporta distribution format for modularcollections softwareof Java code and associated resources. It also specifies a repository for storing these collections, termedor "Java''[[Modular Platformprogramming|modules]]'', Moduleand System"identifies how they can be discovered, whichloaded isand controlledchecked onfor sourceintegrity. levelIt includes features such as namespaces with module-info.javathe aim of fixing some of the shortcomings in the existing [[JAR (file format)|JAR]] filesformat. ItThe 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 itthe Java Platform Module System does not offer the ability for controlled co-existence of libraries with different versions, it isdoes not suited forfully tacklingaddress the JAR Hellhell problem.<ref>{{cite web|first1=Neil|last1=Bartlett|first2=Kai|last2=Hackbarth|title=Java 9, OSGi and the Future of Modularity (Part 1)

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

|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 version history#Java SE 9|Java 9]]. Released in 2017, it includes support for modular software, termed "Java Platform Module System", which is controlled on source level with module-info.java files. It 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 it does not offer the ability for controlled co-existence of libraries with different versions, it is not suited for tackling 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)

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

Line 118 ⟶ 104:

* Chuck McManis, "[https://www.infoworld.com/article/2077260/learn-java-the-basics-of-java-class-loaders.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] {{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