Java Classloader - Java Classloader

A Java osztálybetöltő a Java futási környezet része, amely dinamikusan betölti a Java osztályokat a Java virtuális gépbe . Általában az osztályokat csak igény szerint töltik be . A Java futási időrendszernek nem kell tudnia a fájlokról és fájlrendszerekről, mivel ezt az osztálybetöltőre delegálja .

A szoftverkönyvtár a kapcsolódó objektumkódok gyűjteménye . A Java nyelven a könyvtárakat általában JAR fájlokba csomagolják . A könyvtárak különböző típusú objektumokat tartalmazhatnak. A Jar fájlban található legfontosabb objektumtípus a Java osztály . Az osztály úgy tekinthető, mint egy megnevezett kódegység. Az osztálybetöltő felelős a könyvtárak megkereséséért, tartalmuk olvasásáért és a könyvtárakban található osztályok betöltéséért. Ez a betöltés általában "igény szerint" történik, mivel addig nem történik meg, amíg a program nem hívja meg az osztályt. Egy adott nevű osztály csak egyszer tölthető be egy adott osztálybetöltővel.

Minden Java osztályt betölteni kell egy osztálybetöltővel. Ezenkívül a Java programok külső könyvtárakat is használhatnak (azaz a program szerzőjén kívül más által írt és biztosított könyvtárakat), vagy legalább részben több könyvtárból is összeállhatnak.

A JVM indításakor három osztályú rakodót használnak:

  1. Bootstrap osztályú rakodógép
  2. Extensions osztályú rakodógép
  3. Rendszerosztályú betöltő

A bootstrap osztály betöltője betölti a könyvtárban található alapvető Java könyvtárakat <JAVA_HOME>/jre/lib. Ez az osztálybetöltő, amely a JVM magjának része, natív kódban van írva.

A kiterjesztések osztálybetöltője betölti a kódot a kiterjesztések könyvtáraiba ( <JAVA_HOME>/jre/lib/extvagy bármely más, a java.ext.dirsrendszertulajdonság által megadott könyvtárba ).

A rendszerosztály betöltője betölti a kódot java.class.path, amely megtalálható a CLASSPATH környezeti változóhoz .

Felhasználó által meghatározott osztályú rakodók

A Java osztály betöltője Java nyelven íródott. Ezért lehetőség van saját osztálybetöltő létrehozására a Java virtuális gép finomabb részleteinek megértése nélkül. Minden Java osztály betöltőnek van szülőosztály -betöltője, amelyet akkor határoznak meg, amikor új osztálybetöltőt hoznak létre, vagy beállítják a virtuális gép rendszer alapértelmezett osztálybetöltőjére.

Ez lehetővé teszi (például):

  • osztályok betöltése vagy kiürítése futásidőben (például a könyvtárak dinamikus betöltése futásidőben, akár HTTP -erőforrásból is). Ez fontos jellemző a következőkhöz:
  • a bytecode betöltési módjának megváltoztatásához (például lehetőség van titkosított Java osztály bytecode használatára).
  • a betöltött bájtkód módosítására (például aspektusok betöltési idejű szövéséhez aspektusorientált programozás esetén ).

Osztályrakodók Jakarta EE -ban

A Jakarta EE (korábban Java EE és J2EE) alkalmazáskiszolgálók jellemzően osztályokat töltenek be egy telepített WAR- vagy EAR -archívumból az osztálybetöltők fája által, elkülönítve az alkalmazást más alkalmazásoktól, de megosztva az osztályokat a telepített modulok között. Az úgynevezett " szervlet konténereket " általában többosztályos rakodók tekintetében valósítják meg.

JAR pokol

A JAR pokol a DLL pokolhoz hasonló kifejezés , amelyet az osztálybetöltési folyamat különböző módjainak leírására használnak. A JAR pokol háromféleképpen fordulhat elő:

  • A rendszerre telepített könyvtár két különböző verziójának véletlen jelenléte. Ezt a rendszer nem fogja hibának tekinteni. A rendszer inkább betölti az osztályokat egyik vagy másik könyvtárból. Ha az új könyvtárat hozzáadja a rendelkezésre álló könyvtárak listájához, ahelyett, hogy lecserélné, az alkalmazás továbbra is úgy viselkedhet, mintha a régi könyvtárat használná.
  • Több könyvtár vagy alkalmazás a foo könyvtár különböző verzióit igényli . Ha a library foo verziói ugyanazokat az osztályneveket használják, nincs mód a könyvtár foo verzióinak betöltésére ugyanazzal az osztálybetöltővel.
  • A legbonyolultabb JAR pokolproblémák olyan körülmények között merülnek fel, amelyek kihasználják az osztálybetöltési rendszer teljes összetettségét. Egy Java programnak nem szükséges csak egyetlen "lapos" osztályú betöltőt használni, hanem több (potenciálisan nagyon sok) egymásba ágyazott, együttműködő osztálybetöltőből állhat. A különböző osztálybetöltők által betöltött osztályok bonyolult módon kölcsönhatásba léphetnek egymással, amelyet a fejlesztő nem ért teljesen, ami hibákhoz vagy hibákhoz vezethet, amelyeket nehéz elemezni, megmagyarázni és megoldani.

Az OSGi Szövetség specifikálta (1998 -ban JSR 8 -ként) egy moduláris keretrendszert, amelynek célja a JAR pokol megoldása a jelenlegi és jövőbeli ME-, SE- és EE -beli virtuális gépek számára, és amelyet széles körben elfogadnak. A JAR- jegyzékben szereplő metaadatok használatával a JAR- fájlok (az úgynevezett kötegek) csomagonként vannak bekötve. A csomagok exportálhatnak csomagokat, importálhatnak csomagokat és titokban tarthatják a csomagokat, biztosítva a modularitás és a változatos függőségkezelés alapvető konstrukcióit.

A JAR pokolproblémáinak orvoslására  2005 -ben elindították a Java közösségi folyamatot - a JSR 277 -et. A Java Platform Module System  - Java Platform Module System - új terjesztési formátumot, egy modulverziót és egy közös (a célhoz hasonló) modul tárolót kíván bevezetni. Microsoft .NET 's Global Assembly Cache ). 2008 decemberében a Sun bejelentette, hogy a JSR 277 -et felfüggesztik. A Java modulrendszert később újraindították "projekt Jigsaw" néven, amelyet a Java 9 tartalmazott .

Lásd még

Lábjegyzetek

Hivatkozások

Külső linkek