Kurze Einführung in ClassLoader – Teil 2
Wenn ein Class Loader eine Klasse laden muss, delegiert er die Anfrage zunächst an seinen “parent class loader”. Erst wenn dieser die gewünschte Klasse nicht finden konnte, probiert er es selber die Klasse zu laden.
Das testen wir doch gerade mal. Wir schreiben zwei Klassen: Customer und Main. Beide Klassen befinden sich im CLASSPATH. In der main-Methode der Main-Klasse werden folgende Objekte geholt:
ClassLoaderdes aktuellen ThreadsClassLoadervonjava.lang.StringClassLoadervonch.javablog.MainClassLoadervonch.javablog.Customer
Alle diese Objekte geben wir auf der Kommandozeile aus.
Beispielcode:
- }
Ausgabe auf der Kommandozeile:
current context classloader: sun.misc.Launcher$AppClassLoader@133056f
java.lang.String classloader: null
ch.javablog.Customer classloader: sun.misc.Launcher$AppClassLoader@133056f
ch.javablog.Main classloader: sun.misc.Launcher$AppClassLoader@133056f
Interpretation:
Der ClassLoader des Threads ist der System ClassLoader (sun.misc.Launcher). Er lädt die String-Klasse nicht selber, sondern delegiert das Laden der String-Klasse an seinen “parent class loader”, dem Bootstrap ClassLoader. Dieser wird nicht als ClassLoader-Objekt repräsentiert, stattdessen wird beim Zugriffsversuch null zurückgegeben.
Die Klassen Customer und Main werden vom System ClassLoader auch an den Bootstrap ClassLoader delegiert. Der kennt sie aber nicht und von daher muss der System ClassLoader diese Klassen selber laden.

Bis jetzt alles noch sehr einfach. Im nächsten Teil schreiben wir einen eigenen ClassLoader…