Java Classloader

Java Class Loader är en del av Java Runtime Environment som dynamiskt laddar Java-klasser till Java Virtual Machine . Vanligtvis laddas klasser endast på begäran . Java-körtidssystemet behöver inte känna till filer och filsystem eftersom detta delegeras till klassladdaren.

Ett programbibliotek är en samling relaterad objektkod . I Java-språket paketeras bibliotek vanligtvis i JAR-filer . Bibliotek kan innehålla föremål av olika typer. Den viktigaste typen av objekt som finns i en Jar-fil är en Java-klass . En klass kan ses som en namngiven kodenhet. Klassladdaren ansvarar för att lokalisera bibliotek, läsa deras innehåll och ladda klasserna som finns i biblioteken. Denna laddning görs vanligtvis "on demand", eftersom den inte sker förrän klassen anropas av programmet. En klass med ett givet namn kan bara laddas en gång av en given klassladdare.

Varje Java-klass måste laddas av en klassladdare. Dessutom Java- program använda externa bibliotek (det vill säga bibliotek skrivna och tillhandahållna av någon annan än programmets författare) eller så kan de bestå, åtminstone delvis, av ett antal bibliotek.

När JVM startas används tre klasslastare:

  1. Bootstrap klass laddare
  2. Förlängningsklasslastare
  3. Systemklass laddare

Klassladdaren för bootstrap laddar de grundläggande Java-biblioteken som finns i katalogen <JAVA_HOME>/jre/lib (eller <JAVA_HOME>/jmods> för Java 9 och högre). Denna klassladdare, som är en del av kärnan JVM, är skriven i inbyggd kod.

Extensionsklassladdaren laddar koden i tilläggskatalogerna ( <JAVA_HOME>/jre/lib/ext , eller någon annan katalog specificerad av java.ext.dirs systemegenskapen).

Systemklassladdaren laddar kod som finns på java.class.path , som mappas till miljövariabeln CLASSPATH .

Användardefinierade klassladdare

Java-klassladdaren är skriven i Java. Det är därför möjligt att skapa din egen klassladdare utan att förstå de finare detaljerna i Java Virtual Machine. Varje Java-klassladdare har en förälderklassladdare, definierad när en ny klassladdare instansieras eller ställs in på den virtuella maskinens systemstandardklassladdare.

Detta gör det möjligt (till exempel):

Klasslastare i Jakarta EE

Jakarta EE (tidigare Java EE och J2EE) applikationsservrar laddar vanligtvis klasser från ett distribuerat WAR- eller EAR -arkiv genom ett träd av klassladdare, vilket isolerar applikationen från andra applikationer, men delar klasser mellan distribuerade moduler. Så kallade " servletcontainrar " implementeras vanligtvis i termer av flera klasslastare.

JAR helvete

JAR helvetet är en term som liknar DLL helvetet som används för att beskriva alla olika sätt på vilka klassladdningsprocessen kan sluta fungera. Tre sätt på vilka JAR-helvetet kan uppstå är:

  • Oavsiktlig närvaro av två olika versioner av ett bibliotek installerat på ett system. Detta kommer inte att betraktas som ett fel av systemet. Snarare kommer systemet att ladda klasser från det ena eller det andra biblioteket. Att lägga till det nya biblioteket i listan över tillgängliga bibliotek istället för att ersätta det kan leda till att programmet fortfarande beter sig som om det gamla biblioteket används, vilket det mycket väl kan vara.
  • Flera bibliotek eller applikationer kräver olika versioner av bibliotek foo . Om versioner av library foo använder samma klassnamn, finns det inget sätt att ladda versionerna av bibliotek foo med samma klass loader.
  • De mest komplexa JAR-helvetesproblemen uppstår under omständigheter som drar fördel av klassladdningssystemets fulla komplexitet. Ett Java-program krävs inte för att bara använda en enda "platt" klassladdare, utan kan istället vara sammansatt av flera (potentiellt väldigt många) kapslade, samverkande klassladdare. Klasser som laddas av olika klassläsare kan interagera på komplexa sätt som inte helt förstås av en utvecklare, vilket leder till fel eller buggar som är svåra att analysera, förklara och lösa.

OSGi Alliance specificerade (som började som JSR 8 1998) ett modularitetsramverk som syftar till att lösa JAR-helvetet för nuvarande och framtida virtuella datorer i ME, SE och EE som är allmänt antagen . Genom att använda metadata i JAR- manifestet kopplas JAR-filer (kallade buntar) per paket. Bundles kan exportera paket, importera paket och hålla paket privata, vilket ger de grundläggande konstruktionerna av modularitet och versionsstyrd beroendehantering.

För att råda bot på JAR-helvetesproblemen initierades en Java Community Process – JSR 277 2005. Resolutionen – Java Platform Module System – syftade till att introducera ett nytt distributionsformat, ett modulversionsschema och ett gemensamt modulförråd (liknande i syfte att Microsoft .NET :s Global Assembly Cache ). I december 2008 meddelade Sun att JSR 277 lades på is. Java Module System startade senare om som "project Jigsaw" som ingick i Java 9 . Den släpptes 2017 och inkluderar stöd för modulär programvara, kallad "Java Platform Module System", som styrs på källnivå med module-info.java-filer. Den följer en annan filosofi än OSGi-arkitekturen som syftar till att tillhandahålla modularitet för Java Runtime Environment på ett bakåtkompatibelt sätt som använder standardmekanismen för laddning av klasser som JRE tillhandahåller. Men eftersom den inte erbjuder möjligheten till kontrollerad samexistens av bibliotek med olika versioner, är den inte lämpad för att ta itu med JAR Hell-problemet.

Se även

Fotnoter

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Java_Classloader&oldid=1097075162 "