Mit maßgeschneiderten Klassenladern lästige Fehler in Java vermeiden

Angenommen, es gibt zwei ähnliche Klassenlader, MyClassLoader1 und MyClassLoader2, die beide den Bytecode von MyCoolClass in derselben Quelle finden können. Falls eine Anwendung mithilfe der beiden Klassenlader zwei Instanzen von MyCoolClass unabhängig voneinander lädt (also etwa coolClass1 durch MyClassLoader1 und coolClass2 durch MyClassLoader2), wird MyCoolClass.class dafür ebenfalls unabhängig definiert. Wird dann der folgenden Code ausgeführt, erhält man die Fehlermeldung ClassCastException:

MyCoolClass coolClass1 = (MyCoolClass)coolClass2;

Diesem Ausnahmefehler werden jene Entwickler häufig begegnen, die den Mechanismus zum Laden von Klassen nicht richtig verstanden haben. Da die beiden Klassen von unterschiedlichen Klassenladern definiert wurden, registriert die JVM zwei unterschiedliche Klassentypen. Die Variablen coolClass1 und coolClass2 sind nicht typkompatibel, obwohl sie denselben Klassentyp haben und von derselben Quelle geladen wurden.

Egal ob findClass() oder loadClass() außer Kraft gesetzt werden, mit der Methode getSystemClassLoader() hat man direkten Zugriff auf den System-Klassenlader in Form eines echten ClassLoader-Objekts. Mit dem Aufruf findSystemClass(String name) lässt sich ebenfalls darauf zugreifen. Die Methode getParent() liefert den übergeordneten Klassenlader. Listing A beinhaltet das Beispiel eines einsatzfertigen, selbst geschriebenen Klassenladers.

Listing A

Zusammenfassung

Wer den Mechanismus des Ladens von Klassen richtig versteht, kann sich langfristig viel Ärger mit dem Debuggen von ClassNotFound– oder ClassCastException-Fehlern in einer Anwendung ersparen. Das ist besonders wichtig, wenn eine Anwendung innerhalb eines Anwendungsservers eines Drittanbieters läuft. Denn solche Anwendungsserver verwenden häufig proprietäre und spezifisch konzipierte Klassenlader.