Entwickler von Java-Enterprise-Applikationen haben oft damit zu kämpfen, dass immer der falsche Klassenlader eine Klasse bezieht und die Typen dann nicht zusammenpassen. In unserem Beispiel mit dem statischen Initialisierungsblock ist gut zu erkennen, dass durch das zweimalige Laden die Laufzeitumgebung auch zweimal die Anweisungen ausführt. Hätten wir Singletons definiert, würden ihre statische Anfragemethoden unterschiedliche, nicht kompatible Objekte liefern, obwohl es laut Defini-tion eines Singletons der Fall sein müsste. Allgemein gesprochen: Besonders Fabrikfunktionen liefern bei mehreren Versionen der Klasse unterschiedliche Objekte, die nicht zusammenpassen. Zwei Lösungen gibt es hier: Zum einen bekommen die Fabrikfunktionen einen Klassenlader, in dessen Kontext sie die Klassen erzeugen können, oder sie nutzen den Klassenlader, der mit einem Thread ver-bunden ist.
Jeder Thread ist mit einem Klassenlader assoziiert, der standardmäßig mit dem Standardklassenlader identisch ist. getContextClassLoader() auf dem Thread-Objekt bezieht diesen Klassenlader:
Listing 8.13 com/tutego/insel/lang/ThreadClassLoader.java, main()
ClassLoader loader = Thread.currentThread().getContextClassLoader();
System.out.println( loader ); // sun.misc.Launcher$AppClassLoader@a12a00
loader = ThreadClassloader.class.getClassLoader();
System.out.println( loader ); // sun.misc.Launcher$AppClassLoader@a12a00
Soll der assoziierte Klassenlader geändert werden, bewerkstelligt dies setContextClassLoader().