Ugrás a tartalomhoz

Java Classloader

A Wikipédiából, a szabad enciklopédiából
A lap korábbi változatát látod, amilyen Zafir (vitalap | szerkesztései) 2012. május 23., 21:48-kor történt szerkesztése után volt. Ez a változat jelentősen eltérhet az aktuális változattól.
 Ez a szócikk/szakasz most épül, még dolgoznak az első verzión!

A szócikk/szakasz építőjének: Ha az építés várhatóan néhány napnál tovább tart, inkább saját allapon végezd! A többieknek: amíg az építés nem fejeződik be, használd a vitalapot, hogy elkerüld a szerkesztési ütközéseket a cikk építőjével!
Legutóbbi módosítás: 2012. május 23.

A Java Classloader része a Java Futtatható környezetnek, amely dinamikusan tölti a Java osztályokat a Java virtuális gépbe.[1] Általában az osztályok kérésre töltődnek csak be. A Java futtatható környezetnek nem kell tudnia a fájlokról, a fájl rendszerről a classloader miatt. A Delegáció egy fontos fogalom, a class loader megértésére.

A szoftver gyűjtemény egy objektum kód szerint rendezett gyűjtemény. 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 jar fájl által tartalmazott objektum típus a java osztály. Az osztály nem más mint a forráskód egy névbe zárása. A class loader felelős a könyvtárak megtalálásáért, olvasásáért, és betölteni az osztályokat a könyvtárakból A betöltés tipikusan kérésre hajtódik végre, amely betöltés nem hajtódik végre ha az adott osztályt egy másik program épp használja. Az osztály az adott nevén csak egy időben csak egyszer töltődhet be az adott class loaderrel.

Minden java osztály a classloader által kell, hogy betöltődjön.[2] Továbbá, Java (programozási nyelv) igénybe vehetnek külső könyvtárakat (ezek a könyvtárak egy a szerzőtől függetlenül megírt és támogatott forrástól származnak) vagy részben külső forrásoktól származó könyvtárakat.

A java futtatható környezet indulásakor három classloader használódik[3][4]:

  1. Bootstrap class loader
  2. Extensions class loader
  3. System class loader

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

Az extensions class loader betölti a kódot az extensions(kiterjesztés) mappából (<JAVA_HOME>/lib/ext, vagy bármilyen olyan mappát, amely a java.ext.dirs van specializálva). Ez sun.misc.Launcher$ExtClassLoader által implementált osztály.

A system class loader betölti java.class.path mutatott kódot, amelyet a CLASSPATH változó mutatott. Ez a sun.misc.Launcher$AppClassLoader által implementált osztály.

Felhasználó átlal definiált class loader

Alapértelmezetten, minden felhasználó által írt osztályt a system class loader tölt be, de lehetséges, hogy kicserélje ez egy felhasználó által kivánt class loader-re.Sablon:Clarify

Ez a következőképpen lehetséges (példa):

  • betölteni, vagy vissza kivenni osztályokat futási időben (példa a dinamikus osztály betöltésre a HTTP resource). Ez egy fontos funkció:
    • script nyelv implementálásához,
    • bean buildereknél,
    • felhasználó engedélyezésekhez extensibility
    • A több névtér kommunikációjához. Ezen alapszik a CORBA / RMI protokol, például.
  • to change the way the bytecode is loaded (for example, it is possible to use encrypted Java class bytecode[6]).
  • megváltoztatni a bájtkód betöltésének útvonalát.
  • módosítani a bájtkód betöltést.

Class Loader-ek a JEE-ben

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

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

Jegyzetek

  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. ↑ These libraries are stored in Jar files called 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

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Java_Classloader&oldid=11749868”