Java Classloader

A Wikipédiából, a szabad enciklopédiából

A Java Classloader (magyarul Java osztálybetöltő), amely dinamikusan tölti be a Java osztályokat a Java virtuális gépbe, része a Java futtató környezetnek (angolul Java Runtime Environment).[1] Az osztályok betöltése a Java virtuális gépbe igény szerint történik. A Java futtatható környezetnek nem kell ismernie a fájlok elhelyezkedését vagy fájl rendszert, mivel ezek felderítését a classloader végzi. A classloader megértéséhez fontos megérteni a delegáció fogalmát.

A szoftverkönyvtár a kapcsolódó objektum kódok egy gyűjteménye. A java programozási nyelv, könyvtárai tipikusan JAR fájlba vannak csomagolva. A könyvtárak különböző objektum típusokat tárolnak. A legfontosabb objektum típus a java osztály jar fájlban. Az osztály nem más, mint a kód egy nevesített egysége. A classloader felelős a könyvtárak megtalálásáért, olvasásáért, és az osztályok különböző könyvtárakból való betöltésért. A betöltés tipikusan kérésre hajtódik végre. Az osztály betöltése nem hajtódik végre, ha az adott osztályt egy másik program már használja. Egy osztály egy adott nevén egy időben csak egyszer töltődhet be egy adott classloaderrel.

Minden java osztályt egy classloader tölt be.[2] Továbbá a Java programok igénybe vehetnek külső könyvtárakat (azaz olyan könyvtárakat, amelyeket más által írt és támogatott forrástól származnak) vagy legalább részben külső forrásokból származó könyvtárakat.

A java futtató környezet indulásához három classloadert használ[3][4]:

  1. Bootstrap classloader
  2. Extensions classloader
  3. System classloader

A bootstrap classloader betölti a főbb java könyvtárakat[5], melyek a <JAVA_HOME>/lib mappába helyezkednek el. Ezt a class loadert, amely része a Java virtuális gépnek, natív kódban írták.

Az extensions classloader betölti a kódot az extensions(kiterjesztés) mappából (<JAVA_HOME>/lib/ext, vagy bármilyen olyan mappából, amelyet a java.ext.dirs meghatároz). Ezt a sun.misc.Launcher$ExtClassLoader osztály valósítja meg.

A system classloader betölti a java.class.path változó által meghatározott osztályokat, amelyet a rendszer CLASSPATH-ára map-olja le. Ezt a sun.misc.Launcher$AppClassLoader osztály valósítja meg.

Felhasználó által definiált classloader[szerkesztés | forrásszöveg szerkesztése]

A Java class loader-t java-ban írják. Ilyen módon lehetséges saját class loadert írni a Java virtuális gép mélyebb ismerete nélkül. Minden Java class loadernek van egy szülő class loader-e, amely meghatározása akkor történik meg, amikor az új class loader példányosítása ill. beállítása a virtuális gép alapértelmezett rendszer class loaderére megtörténik.

Mindez lehetővé teszi a következőket (pl):

  • betölteni, vagy visszatölteni osztályokat futási időben (példa a dinamikus osztály betöltésre a HTTP resource). Ez egy fontos tulajdonság a következőkhöz:
    • script nyelv implementálásához,
    • bean buildereknél,
    • felhasználó engedélyezésekhez kiterjesztéséhez
    • A több névtér kommunikációjához. Ezen alapszik a CORBA / RMI protokol, például.
  • megváltoztatni annak a módját, ahogy a bájtkód betöltődik (pl. lehetséges kódolt Java class bájt kódot használni[6]).
  • megváltoztatni a bájt kód betöltésének útvonalát.
  • módosítani a bájt kód betöltést.

Classloader-ek a JEE-ben[szerkesztés | forrásszöveg szerkesztése]

A Java Platform, Enterprise Edition (JEE) alkalmazás szerver tipikusan WAR fájlból tölti be vagy EAR faként csomagolt class loader, elszigeteli az alkalmazást más alkalmazásoktól, de megossza a modult a telepített modulok közt. Úgynevezett "servlet gyűjtemények" tipikusan összetett class loader-ekhez vannak implementálva.[2][7]

JAR hell[szerkesztés | forrásszöveg szerkesztése]

JAR hell nagyon hasonlóan a DLL hell-hez leírja az összes lehetséges utat, amellyel az osztály betöltő funkció megállhat.[8] Három út amely JAR hell-t okozhat:

  • Az első változat amikor a fejlesztő vagy a telepítő véletlenül két különböző verziójú könyvtárt csinál az elérhető rendszerben. Ezt a rendszer nem fogja hibaként kijelezni. Inkább megpróbálja a rendszer betölteni az egyikből, vagy egy teljesen másikból. Új könyvtár hozzáadása a régiek mellé, ahelyett hogy kicserélődne a régi az újra, ezért az alkalmazás a régi könyvtárat fogja, használni a frissebb helyett.
  • Másik verzió probléma mikor két könyvtár egy harmadikat szeretne használni, de eltérő verzióval. Ha mindkét verzióban ugyanazokat az osztályneveket használják, nincs lehetőség betölteni az osztályt ugyanazzal az osztálybetöltővel.
  • A legkomplexebb JAR hell probléma előfordulás olyan körülmények esetén, amely olyan előnyöket ad az osztálybetöltő rendszernek.A java program nem követeli meg az egyedüli osztálybetöltő használatát. Osztályokat betölthetünk több más osztály betöltővel., amelyek egymásba vannak ágyazva, és együttműködnek egymással. A több osztálybetöltővel betöltött osztályok kölcsönhatásba kerülnek egymással, amelyet a fejlesztő nem biztos, hogy tud követni. Megmagyarázhatatlan hibákhoz vezet ez által.[9]

Az OSGi szövetség lerögzített (starting as JSR 8 in 1998) egy moduláris keretrendszert, amely megoldja a JAR hell problémát jelenleg és a jövőben széles körben. Meta adatot használva a JAR fájlban manifest be vannak kötve egy "pre-package" bázishoz. Határtalanul lehet exportálni, importálni csomagokat, az import csomagok megőrzik az alapvető konstrukciójukat, modularitásukat, és verziózott függőségüket.

A gyógyír a JAR hell problémákra a Java Community Process - jsr 277, amelyet 2005-ben hívtak életre. Határozat született az új forgalmazási formátumra, modul verzió sémára, és közös tároló modulokra.(mint ahogy a Microsoft .NET's Global Assembly Cache). 2008 decemberében a Sun bejelenetette hogy JSR 277 elhalasztotta.[10]

Lásd még[szerkesztés | forrásszöveg szerkesztése]

Jegyzetek[szerkesztés | forrásszöveg szerkesztése]

  1. Mcmanis, Chuck: The basics of Java class loaders. JavaWorld, 1996. október 1. (Hozzáférés: 2008. január 26.)
  2. ^ a b Christudas, Binildas: Internals of Java Class Loading. onjava.com, 2005. január 26. (Hozzáférés: 2009. október 2.)
  3. Understanding Extension Class Loading. java.sun.com, 2008. február 14. (Hozzáférés: 2009. december 8.)
  4. Sosnoski, Dennis: Classes and class loading. ibm.com, 2003. április 29. (Hozzáférés: 2008. január 26.)
  5. Ezek a könyvtárak a következő Jar fájlokban helyezkednek el: rt.jar, core.jar, server.jar, etc.
  6. Roubtsov, Vladimir: Cracking Java byte-code encryption. javaworld.com, 2003. május 9. (Hozzáférés: 2008. január 26.)
  7. J2EE Class Loading Demystified. ibm.com, 2002. augusztus 21. (Hozzáférés: 2008. január 26.)
  8. http://incubator.apache.org/depot/version/jar-hell.html
  9. http://articles.qos.ch/classloader.html
  10. http://www.osgi.org/News/20081217

Külső hivatkozások[szerkesztés | forrásszöveg szerkesztése]

Fordítás[szerkesztés | forrásszöveg szerkesztése]

Ez a szócikk részben vagy egészben a Java Classloader című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel.