Java Reference
In-Depth Information
!
Falls der Wurzel-Server die Klasse lädt, ist die Aktion damit abgeschlossen. Andernfalls
bekommt der Nachfolger, von dem der Wurzel-Server kontaktiert wurde, die Chance des
Ladens.
!
So geht es dann weiter, bis einer der Vorgänger die Klasse geladen hat oder die Anforde-
rung wieder zu dem ClassLoader-Objekt zurückkehrt, das ursprünglich damit beau ragt
wurde.
!
Dieser ClassLoader hat dann erst die Möglichkeit zum Laden der Klasse. Wenn auch er
die Klasse nicht laden kann, ist der Vorgang fehlgeschlagen, andernfalls erfolgreich abge-
schlossen.
Das Hochreichen der Auff orderung zum Klassenladen bis zur Wurzel dient dem Schutz der
Java-Kernklassen, denn somit kann ein eigener ClassLoader keine Klasse wie z. B. java.lang.
String laden.
Der oben geschilderte Ablauf bedeutet, dass sich die Klasse, die man durch ein eigenes
ClassLoader-Objekt laden möchte, nicht im CLASSPATH befi nden darf, denn sonst wird sie
spätestens durch den Wurzel-ClassLoader geladen. Mit anderen Worten: Man muss allen
anderen ClassLoader-Objekten die Möglichkeit nehmen, die Klasse laden zu können.
Eine weitere Konsequenz dieser Strategie des Klassenladens ist, dass von einer Klasse A1,
die von einem ClassLoader cl1 geladen wurde, nicht auf eine Klasse A2, die von einem
anderen ClassLoader cl2 geladen wurde, zugegriff en werden kann, falls cl2 kein direkter
oder indirekter Vorgänger von cl1 im ClassLoader-Baum ist. Sollten Sie diese Konsequenz
im Moment nicht nachvollziehen können, so spielt dies erst einmal keine Rolle. Wir werden
auf diese Problematik bei der prototypischen Implementierung eines eigenen Komponen-
tensystems nochmals zurückkommen. Anhand eines konkreten Beispiels wird der Sachver-
halt dann einfacher zu verstehen sein.
Um ein eigenes ClassLoader-Objekt zu erzeugen, braucht man nicht unbedingt eine eigene
ClassLoader-Klasse zu implementieren, sondern man kann auf die Klasse URLClassLoader
zurückgreifen. Diese hat u. a. die folgenden Konstruktoren:
public URLClassLoader(URL[] urls, ClassLoader parent) {...}
public URLClassLoader(URL[] urls) {...}
Das Argument urls enthält eine Folge von Verzeichnissen und Jar- bzw. Zip-Dateien, die der
Reihe nach durchsucht werden, um die zu ladende Klasse zu fi nden (wie der Datentyp URL
andeutet, können sich diese auch auf anderen Rechnern befi nden). Der zweite Parameter
des ersten Konstruktors gibt die Stelle an, wo das neue ClassLoader-Objekt im Baum aller
ClassLoader angehängt werden soll. Im zweiten Konstruktor entfällt diese Angabe. In die-
sem Fall wird ein Standard-System-Klassenlader als Vorgänger des neuen ClassLoaders ver-
wendet.
Wenn im Code einer Klasse A die Klasse B benötigt wird, so wird bei automatischem Laden
der Klassenlader, der A geladen hat, beau ragt auch B zu laden. Man kann aber das Laden
von Klassen auch explizit durch Aufruf von loadClass auf ein spezifi sches ClassLoader-
Objekt anstoß en.
