Java Classloader
Java Classloader je v informatice součást běhového prostředí Javy (JRE), které umožňuje dynamické načítání Java tříd do Java Virtual Machine (JVM). Obvykle se třídy načítají pouze při jejich potřebě, tj. za běhu programu (lazy initialization). Java nemusí znát přesně všechny soubory a souborové systémy, z důvodu použití právě classloaderu. Funkci classloaderu zajišťuje koncept delegace.

Softwarová knihovna je sbírka souvisejícího objektového kódu. V Javě, se knihovny typicky zabalují do JAR souborů. Knihovny mohou obsahovat objekty různých datových typů. Nejdůležitějším typem objektu nacházejícím se JAR souboru je Java třída. Třída v tomto případě je myšlena jako pojmenování jednotky kódu. Classloader zajišťuje vyhledání místa, kde se nacházejí knihovny, čtení jejich obsahu a tedy i načítání tříd z těchto knihoven. Načítání typicky probíhá za běhu programu „na požádání“, což znamená, že se třída načte až v případě, kdy bude programem používána. Každá třída může být načtena pouze jediným daným classloaderem.

Každá třída v Javě musí být načtena pomocí classloaderu. Navíc programy v Javě mohou používat externí knihovny (to jsou knihovny  napsané a poskytované někým jiným než je autor programu) nebo můžeme čerpat pouze části kódu z několika knihoven.

Když se JVM (Java virtual machine) spustí, jsou používány následující 3 knihovny:
 Bootstrap class loader
 Extensions class loader
 System class loader

Bootstrap classloader načte třídy core Java knihoven (runtime třídy), které se nacházejí ve složce <JAVA_HOME>/jre/lib. Tento classloader, jehož část obsahuje jádro JVM, je v nativním (strojovém) kódu.

Extensions classloader načte kód z adresářů, které obsluhují různá rozšíření (<JAVA_HOME>/jre/lib/ext nebo načítá i z jiných adresářů specifikovaných ve specifikaci systému java.ext.dirs). Tato definice je implementována ve třídě sun.misc.Launcher$ExtClassLoader.

System classloader načte kód, který nalezne v java.class.path třídy, které chceme načíst, nalezneme v proměnné CLASSPATH. Vše je implementováno ve třídě sun.misc.Launcher$AppClassLoader.

Uživatelsky definované class loadery 
Java classloader je oproti jádru JVM, napsaný v Javě. Je tedy možné si v samotné Javě vytvořit svůj vlastní class loader bez nutnosti znát přesně detailní strukturu Java Virtual Machine. Každý Java classloader má nadřazený classloader, ten musí být definován ještě před vytvořením jeho instance nebo musí být nastaven v výchozím classloaderu Java Virtual Machine.

Díky tomu je možné například:
 načítat nebo odebírat třídy za běhu programu (načítání dynamických tříd za běhu programu, například z HTTP zdrojů). Toto jsou podstatné vlastnosti pro:
 implementaci skriptovacích jazyků,
 použití bean builderů,
 podporu uživatelsky definovatelné rozšiřitelnosti,
 umožňuje používat více jmenných prostorů, s tímto se můžeme setkat při používání protokolů CORBA / RMI,
 změna způsobu načítání bytekódu, využití nalezne v zabezpečení, kde lze využít šifrovaného bytekódu).
 změnu již načteného bytekódu, které nalezne využití například v Aspektově orientovaném programování, konkrétně v utilitě zajišťující podporu load-time weavingu.

Class Loadery v JEE 
Java Platform, Enterprise Edition (JEE) aplikační servery většinou načítají třídy z WAR nebo EAR souborů, které jsou sestaveny do stromu classloaderů, tímto oddělují naši aplikaci od jiných aplikací, ale dokáží sdílet jednotlivé třídy, které aplikace obsahuje, mezi nasazené moduly v ostatních aplikacích. Takzvané „servlet kontejnery“ jsou typickou implementací použití vícenásobných class loaderů.

JAR hell 
JAR hell je výraz podobající se tzv. DLL hell. Používá se k popisu všech různých způsobů, který proces načítání tříd může jakýmkoliv způsobem narušit nebo i úplně ukončit. Existují 3 možnosti, kdy JAR hell může nastat:

 Vývojář nebo deployer Java aplikace vytvoří nechtěně dvě různé verze knihoven, které jsou dostupné v systému. V systému toto není považováno za chybu a obě verze přijme. V tomto případě se třídy mohou načítat z jedné nebo druhé knihovny, kde mezi jednotlivými verzemi se samozřejmě mohou vyskytovat rozdíly. Přidání nové knihovny do seznamu načítaných knihoven namísto jejího nahrazení způsobí načítání některých tříd ze staré neopravené knihovny. Systém se tedy bude chovat tak, jako kdyby používal verzi starou.

 Dvě knihovny (nebo knihovna a aplikace) požadují různé verze stejné třetí knihovny. Pokud obě verze třetí knihovny obsahují stejné názvy tříd, neexistuje způsob jak načíst obě verze třetí knihovny s použitím jednoho a téhož classloaderu.

 Mezi komplexní problémy JAR hell patří takové, které využívají plnou složitost systému načítání tříd. Každý java program nemusí používat pouze jeden „plochý“ classloader, ale místo toho může být složen z více různých (většinou z mnoha) provázaných, navzájem spolupracujících classloaderů. Třídy načítané různými classloadery mohou ale ve své vzájemné návaznosti vytvářet neočekávané komplexní problémy, které při nepochopení vývojářem aplikace, často způsobují neočekávané výstupy a chyby, které mohou způsobit i pád programu.

Pro odstranění těchto problémů s JAR hell byla aliancí OSGi uvedena specifikace (pod původním názvem JSR 8 z roku 1998) modulárního frameworku. Toto řešení je v současnosti používáno ve virtuálních strojích v Java ME, SE a EE. Ve všech těchto uvedených verzích Javy je předpokládáno i použití specifikace ve verzích následujících. Hlavní myšlenkou této specifikace závisí na použití metadat v JAR manifestu, JAR soubory (neboli tzv. bundles) jsou sestaveny na základě jednotlivých balíčků (package). Bundles poté mohou jednotlivé balíčky exportovat, importovat, přidělovat jim přístupová práva, určovat strukturu pro další rozšířitelnost a také dokáží spravovat tzv. verzování.

K předcházení problémům s JAR knihovnami vznikla v roce 2005 pracovní skupina Java Community Process – JSR 277. Rozlišuje tzv. Java Module System, který má za cíl určit nový distribuční formát, schéma modulu podporujících verzování a společné úložiště tzv. repozitáře (s podobnými vlastnosti již funguje Microsoft .NET Global Assembly Cache). V prosinci Sun vyhlásil JSR 277 jako „dormant“, tedy je prohlášen za svou finální verzi.

Poznámky

Reference

Související články 
 Zavaděč (program)
 Dynamic loading
 DLL peklo
 OSGi

Externí odkazy 
 Chuck McManis, "The basics of Java class loaders ", 1996
 Brandon E. Taylor, "Java Class Loading: The Basics ", 2003
 Jeff Hanson, "Take Control of Class Loading in Java ", 2006-06-01
 Andreas Schaefer, "Inside Class Loaders", 2003-11-12
 Sheng Liang and Gilad Bracha, "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. 36–44

 Dr. Christoph G. Jung, "Classloaders Revisited Hotdeploy ", Java Specialist Newsletter, 2001-06-07
 Don Schwarz, "Managing Component Dependencies Using ClassLoaders", 2005-04-13

Java