Java class loader - Revision history

Netjeff: /* JAR hell */ punctuation

2024-11-26T18:15:00Z

JAR hell: punctuation

← Previous revision		Revision as of 18:15, 26 November 2024
Line 84:		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.		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.

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

Netjeff: /* JAR hell */ Updated the paragraph about the Java Platform Module System. Less detailed history, and used summary from the full wiki page

2024-11-26T18:13:39Z

JAR hell: Updated the paragraph about the Java Platform Module System. Less detailed history, and used summary from the full wiki page

← Previous revision		Revision as of 18:13, 26 November 2024
Line 84:		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.		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.

		⚫	[[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)
	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.<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>		\|url=https://www.infoq.com/articles/java9-osgi-future-modularity/#1\|publisher=InfoQ\|date=2016-09-22}}</ref>

BarrelProof: Sentence case

2024-11-17T13:41:51Z

Sentence case

← Previous revision		Revision as of 13:41, 17 November 2024
Line 1:		Line 1:
	The '''Java ~~Class~~ ~~Loader~~''', part of the [[Java Runtime Environment]], [[Dynamic loading\|dynamically loads]] [[Java class]]es into the [[Java virtual machine\|Java Virtual Machine]].<ref>{{cite web		The '''Java class loader''', part of the [[Java Runtime Environment]], [[Dynamic loading\|dynamically loads]] [[Java class]]es into the [[Java virtual machine\|Java Virtual Machine]].<ref>{{cite web
	\|last1=Mcmanis \|first1=Chuck		\|last1=Mcmanis \|first1=Chuck
	\|date=1996-10-01 \|df=mdy		\|date=1996-10-01 \|df=mdy

BarrelProof: BarrelProof moved page Java Classloader to Java class loader over redirect: Change to sentence case (MOS:AT)

2024-11-17T13:41:23Z

BarrelProof moved page Java Classloader to Java class loader over redirect: Change to sentence case (MOS:AT)

← Previous revision	Revision as of 13:41, 17 November 2024
(No difference)

BarrelProof: /* {{anchor|jarhell}} JAR hell */ MOS:DASH

2024-11-17T13:38:40Z

{{anchor|jarhell}} JAR hell: MOS:DASH

← Previous revision		Revision as of 13:38, 17 November 2024
Line 84:		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.		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.

	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.<ref>{{cite web		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.<ref>{{cite web
	\|url=https://blogs.oracle.com/mr/entry/jigsaw		\|url=https://blogs.oracle.com/mr/entry/jigsaw
	\|title=Project Jigsaw		\|title=Project Jigsaw

Naruyoko: /* User-defined class loaders */ WP:YOU

2024-10-21T18:02:56Z

User-defined class loaders: WP:YOU

← Previous revision		Revision as of 18:02, 21 October 2024
Line 47:		Line 47:

	==User-defined class loaders==		==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. 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.		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.

	This makes it possible (for example):		This makes it possible (for example):

Liz: Removing link(s) Wikipedia:Articles for deletion/IBM Developer closed as soft delete (XFDcloser)

2024-09-07T02:43:37Z

Removing link(s) Wikipedia:Articles for deletion/IBM Developer closed as soft delete (XFDcloser)

← Previous revision		Revision as of 02:43, 7 September 2024
Line 32:		Line 32:
	\|url=http://www.ibm.com/developerworks/java/library/j-dyn0429/		\|url=http://www.ibm.com/developerworks/java/library/j-dyn0429/
	\|title=Classes and class loading		\|title=Classes and class loading
	\|work=[[IBM DeveloperWorks]]		\|work=IBM DeveloperWorks
	\|accessdate=2008-01-26		\|accessdate=2008-01-26
	}}</ref>{{sfn \| Horstmann \| 2022 \| loc=§10.1.1 The Class-Loading Process}}		}}</ref>{{sfn \| Horstmann \| 2022 \| loc=§10.1.1 The Class-Loading Process}}
Line 72:		Line 72:
	\|url=https://www.ibm.com/developerworks/websphere/library/techarticles/0112_deboer/deboer.html		\|url=https://www.ibm.com/developerworks/websphere/library/techarticles/0112_deboer/deboer.html
	\|title=J2EE Class Loading Demystified		\|title=J2EE Class Loading Demystified
	\|work=[[IBM DeveloperWorks]]		\|work=IBM DeveloperWorks
	\|accessdate=2008-01-26		\|accessdate=2008-01-26
	}}</ref>		}}</ref>

RedYetiDev: Reword intro

2024-04-02T15:11:26Z

Reword intro

← Previous revision		Revision as of 15:11, 2 April 2024
Line 1:		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\|Java Virtual Machine]].<ref>{{cite web		The '''Java Class Loader''', part of the [[Java Runtime Environment]], [[Dynamic loading\|dynamically loads]] [[Java class]]es into the [[Java virtual machine\|Java Virtual Machine]].<ref>{{cite web
	\|last1=Mcmanis \|first1=Chuck		\|last1=Mcmanis \|first1=Chuck
	\|date=1996-10-01 \|df=mdy		\|date=1996-10-01 \|df=mdy

Codexor: Fixed typo, "boostrap" -> "bootstrap".

2024-01-09T02:56:35Z

Fixed typo, "boostrap" -> "bootstrap".

← Previous revision		Revision as of 02:56, 9 January 2024
Line 39:		Line 39:
	# System 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> (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 ~~boostrap~~ 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 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 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		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

Frap: /* Class Loaders in Jakarta EE */ MOS:HEAD

2023-07-08T10:23:36Z

Class Loaders in Jakarta EE: MOS:HEAD

← Previous revision		Revision as of 10:23, 8 July 2023
Line 65:		Line 65:
	* to modify the loaded bytecode (for example, for load-time [[aspect weaver\|weaving]] of aspects when using [[aspect-oriented programming]]).		* to modify the loaded bytecode (for example, for load-time [[aspect weaver\|weaving]] of aspects when using [[aspect-oriented programming]]).

	== Class ~~Loaders~~ in Jakarta EE ==		== Class loaders 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		[[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		\|last1=deBoer \|first1=Tim

← Previous revision		Revision as of 18:15, 26 November 2024
Line 84:		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.		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.

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

← Previous revision		Revision as of 13:41, 17 November 2024
Line 1:		Line 1:
	The '''Java ~~Class~~ ~~Loader~~''', part of the [[Java Runtime Environment]], [[Dynamic loading\|dynamically loads]] [[Java class]]es into the [[Java virtual machine\|Java Virtual Machine]].<ref>{{cite web		The '''Java class loader''', part of the [[Java Runtime Environment]], [[Dynamic loading\|dynamically loads]] [[Java class]]es into the [[Java virtual machine\|Java Virtual Machine]].<ref>{{cite web
	\|last1=Mcmanis \|first1=Chuck		\|last1=Mcmanis \|first1=Chuck
	\|date=1996-10-01 \|df=mdy		\|date=1996-10-01 \|df=mdy

← Previous revision		Revision as of 15:11, 2 April 2024
Line 1:		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\|Java Virtual Machine]].<ref>{{cite web		The '''Java Class Loader''', part of the [[Java Runtime Environment]], [[Dynamic loading\|dynamically loads]] [[Java class]]es into the [[Java virtual machine\|Java Virtual Machine]].<ref>{{cite web
	\|last1=Mcmanis \|first1=Chuck		\|last1=Mcmanis \|first1=Chuck
	\|date=1996-10-01 \|df=mdy		\|date=1996-10-01 \|df=mdy