Class Loader. Seminarbericht Enterprise Computing. Urs Frick, Ie01

Transkript

1 Urs Frick, Ie01 Departement Technik Studiengang Informatik Betreuender Dozent: Prof. Dr. D. Gruntz 12. Februar 2004

2 Abstract Die Java Klassenlader bieten die Möglichkeit Java Klassen zur Laufzeit von einer beliebigen Quelle (Repositories) zu Laden und diese in verschiedene Namensräume zu platzieren. Dieser Bericht beschreibt die genannten Funktionen und gibt eine breite Übersicht über die verschiedenen Aspekte der Java Klassenlader. Neben der Beschreibung der Klasse ClassLoder wird auch beschrieben wie die Klasse ClassLoader zu erweitern ist und was bei der Implementation für die verschiedenen Java Versionen zu beachten ist, um Kompatibilität zu gewähren. Beschrieben wird auch das Delegation Model für die Java 2 Plattform. Auch die Typensicherheit im Zusammenhang mit Klassenladern ist Teil dieses Berichtes. Urs Frick Seite 2 von 28

3 Inhalt Einleitung 5 1. Die Klasse ClassLoader Allgemein Wichtige Methoden Methode loadclass Methode defineclass Methode findsystemclass Methode resolveclass Methode findloadedclass Methode findclass 7 2. ClassLoder Erweiterung nach Java SimpleClassLoader1.java 8 3. Klassenlader nach Java Delegation Model Exkurs: Delegation Pattern Beispiel SimpleClassLoder2.java Klassenlader in der JVM Bootstrap Klassenlader Extension Klassenlader System (oder Application) Klassenlader Beispiel: Class.forName() Lösungen zu Beispiel Class.forName() Thread.getContextClassLoader() Argumente-Form von Class.forName() Multiple Klassenlader Namespaces Beispiel: Multiple Klassenlader Typensicherheit Typensicherheit bei Delegation Problem Lösung Anwendungen Server Applikationen am Beispiel von Apache Tomcat Sicherheit Verschlüsselung / Entschlüsselung von Klassen Archivierung Selbst-Extrahierende Programme Dynamisches generieren von Klassen Ausblick auf das Application Isolation API 21 Quellenverzeichnis 23 Urs Frick Seite 3 von 28

4 Anhang A: SimpleClassLoader1 24 Anhang B: SimpleClassLoader2.java 26 Anhang C: DynamicLoader, Echo 28 Urs Frick Seite 4 von 28

5 Einleitung Die Programmiersprache Java wurde ursprünglich dazu entwickelt um mittels Applets die Möglichkeit zu bieten, Programme über das Internet auszuführen. Im Gegensatz zu anderen Programmiersprachen wird Java auf einer Virtual Machine (VM) ausgeführt. Die Class-Files die im plattformunabhängigen Bytecode zur Verfügung gestellt werden, werden durch die VM geladen und interpretiert. Im Falle von Applets wird die VM vom Browser gestartet. Auf dieser VM können nun beliebig viele Applets ausgeführt werden, die von irgendeinem Server aus dem Internet angeboten werden. Die Anzahl der Applets ist dabei nur durch die Systemressourcen begrenzt. Applet 1 Applet n Browser JVM Das Laden der Applets erfolgt dabei mit einem erweiterten Klassenlader (URLClassLoader). Dieser öffnet ein HTTP-Verbindung zum Server, der die Applet-Klasse bereitstellt, lädt die Klasse als folge von Bytes auf den lokalen Rechner und übergibt sie der VM zur Interpretation. Der Code wird dann auf dem Rechner ausgeführt. An diesem Beispiel lassen sich zwei der wichtigsten Aspekte des Klassenladers veranschaulichen. Erstens ist es möglich den Code von irgendwo her zu laden. Es währe also auch möglich den Code direkt aus einer Datenbank zu laden, oder wie es die Praxis zeigt aus einem komprimierten ZIP-File. Weiter wird veranschaulicht, dass auf einer VM mehrere Programme ausgeführt werden könne, ohne dass dabei Konflikte durch gleiche Klassennamen oder durch den Zugriff auf gemeinsame Ressourcen entsteht. Nachfolgend wird auf die Klasse ClassLoader und auch auf die Konzepte eingegangen, die mit den Klassenlader 1 einhergehen. Neben einem Tutorial zur Erweiterung des ClassLoaders für die Java Versionen 1.1 und die Java 2 Plattform werden auch einige Anwendungsmöglichkeiten beschrieben. Weiter wird auch auf die Typensicherheit in Verbindung mit Klassenlader eingegangen. 1 In diesem Dokument wird zwischen ClassLoader und Klassenlader unterschieden. Mit "ClassLoader" wird die Library-Klasse java.lang.classloader angesprochen. Mit Klassenlader ist eine beliebige Implementation eines Klassenladers gemeint. Urs Frick Seite 5 von 28

6 1. Die Klasse ClassLoader 1.1. Allgemein Die Klasse ClassLoader ist dafür verantwortlich Klassen zu laden. Durch einen gegebenen Klassennamen, versucht der Klassenlader entsprechende Daten zu finden oder zu generieren, mit welchen eine Klassendefinition erstellt werden kann. Jede Klasse die durch einen Klassenlader geladen wird, erhält implizit eine Referenz auf den entsprechenden Klassenlader. Auf die damit verbundenen Konsequenzen wird später in Punkt Multiple Klassenlader eingegangen. Applikationen die das Laden von Klassen erweitern wollen, müssen entsprechend eigene Klassenlader implementieren, die von ClassLoader ableiten. Die Klassenlader ab Java Version 2 wenden das Delegation-Pattern an. Jeder Klassenlader wird mit einem Parent-Klassenlader assoziiert. Jeder Klassenlader delegiert nach diesem Modell die Suche nach einer Klasse zuerst an seinen Parent, bis zum Klassenlader der VM, dem sog. Bootstrap Klassenlader. In Punkt Erweiterung nach Java 1.2 wird genauer auf das Delegation-Pattern eingegangen. Wie bereits in der Einleitung erwähnt, können die Class-Files von einer beliebigen Quelle stammen oder durch eine Applikation erstellt werden. Die Methode ClassLoader.defineClass konvertiert die Klasse, die nach dem Laden durch einen Byte-Array repräsentiert wird, in eine Instanz einer Class Klasse. Neue Instanzen können mit newinstance auf Class erzeugt werden. Klassen die durch den Klassenlader geladen wurden, können ihrerseits wieder Referenzen auf andere Klassen haben. Um diese Klassen zu laden wird ClassLoader.loadClass() des Klassenladers der referenzierenden Klasse aufgerufen. D. h. die referenzierende und die referenzierte Klasse gehören zum gleichen Klassenlader Wichtige Methoden Methode loadclass Signatur: Class loadclass (String name, boolean resolve) Der Parameter name definiert die Klasse die geladen werden soll und zwar in der Package Notation (z.b. java.lang.string). Der Parameter resolve gibt an, ob die Klasse weiter aufgelöst werden soll (siehe "Methode resolveclass()"). In der Java Version 1.1 (und früheren Java Versionen) war die Methode loadclass() die einzige Methode die überschrieben werden musste, um einen eigenen Klassenlader zu implementieren. In Java 2 wurde das geändert. In den Punkten "ClassLoader Erweiterung nach Java 1.1" und "Klassenlader nach Java 2" wird genauer darauf eingegangen. Urs Frick Seite 6 von 28

7 Methode defineclass Die Methode defineclass ist das Kernstück des ClassLoaders. Sie übernimmt einen Byte- Array, welcher das Class-File repräsentiert, das zuvor geladen wurde. Die Methode defineclass übernimmt eine menge komplexer Aufgaben. Sie interpretiert den Bytecode und führt ihn in ein Objekt des Typs Class über. Dabei erfolgen Validitäts- und Sicherheitsprüfungen. Der Prozess ist dabei von der Implementation der VM abhängig. Die Methode defineclass ist darum final definiert Methode findsystemclass Mit findsystemclass wird versucht eine Klasse mit dem System Klassenlader zu laden (siehe "System (oder Application) Klassenlader"). Über findsystemclass kann man dadurch alle Java Library Klassen, die Extension Klassen und alle Klassen auf dem Klassenpfad (CLASSPATH) laden Methode resolveclass Die Methode resolveclass ist für das Linken der Klasse verantwortlich. Wurde eine Klasse mit defineclass definiert, wird sie mit resolveclass für das Ausführen bereit gemacht. Dabei werden auch alle symbolischen Referenzen der Klasse definiert und aufgelöst. Das Auflösen einer Klass ist nicht immer nötig; z.b. dann nicht, wenn die VM nur bestimmen muss, ob eine Klasse vorhanden ist oder um die Superklasse einer Klasse zu bestimmen Methode findloadedclass Die ClassLoaders unterhalten jeweils einen Cache für bereits geladene Klassen. findloadedclass untersucht, ob die Klasse bereits im Cache vorhanden ist und liefert entsprechend eine Objekt vom Typ Class zurück, wenn die Suche erfolgreich war Methode findclass Die Methode findclass wurde in Java 2 in Zusammenhang mit dem Delegation Pattern eingeführt. Ab Java 2 soll loadclass nicht mehr überschrieben werden. Stadt dessen soll mit dem Aufruf von findclass die entsprechende Klasse gesucht und bereitgestellt werden. 2. ClassLoder Erweiterung nach Java 1.1 Obwohl zum Zeitpunkt des Erestellens dieses Berichtes bereits Java Version 1.4.2_03 zur Verfügung steht, wird an dieser Stelle die korrekte Implementation eines Java 1.1 Klassenladers erläutert. Das aus folgenden Gründen: Zum einen findet diese Java Version immer noch Anwendung z.b. in älteren Browserversionen. Zum anderen veranschaulicht das nachfolgende Beispiel [5] ziemlich genau, was bei Java 2 durch das Delegation Model unter der Oberfläche passiert. In diesem Zusammenhang wird nach dem Beispiel der Source-Code von loadclass() aufgelistet, wie er in Java 2 implementiert ist. Urs Frick Seite 7 von 28

8 Bei der Erstellung einer eigenen Implementation eines Klassenladers empfiehlt es sich folgende Punkte einzuhalten. Man sollte von dieser Reihenfolge nur abweichen, wenn man die Probleme der Typensicherheit (siehe "Typensicherheit") verstanden hat. Ansonsten können unerwartete Fehler auftreten. Überprüfen, ob die Klasse bereits geladen ist: Zu diesem Zweck wird eine Map der bereits geladenen Klassen geführt. Die VM verlangt für den gleichen Klassennamen immer dieselbe Instanz der Klasse Class. Versuch Klasse über den übergeordneten System Klassenlader zu laden: In Java 2 wird dies durch das Delegation Pattern gelöst, wobei jeweils an den Übergeordneten Klassenlader delegiert wird. Im Falle von Java 1.1 wird an dieser Stelle einfach an den System Klassenlader übergeben. Nur falls der System Klassenlader die Klasse nicht findet, soll die Klasse vom eigenen Repository geladen werden. Ansonsten wird an dieser Stelle die Instanz der Klasse Class zurückgegeben, die findsystemclass liefert. Versuch Klasse aus dem eigenen Repository zu laden: An dieser Stelle kann versucht werden entsprechenden Bytecode vom eigenen Repository zu laden. Definieren der Klasse für die VM: Hier wird der geladene Bytecode an defineclass übergeben. defineclass liefert dann ein Objekt des Typs Class zurück. Auflösen der Klassen Aufruf der Methode resolveclass Class Objekt zurückgeben Die Instanz der Klasse Class wird an dieser stelle in die Map eingetragen und danach zurückgegeben SimpleClassLoader1.java Der SimpleClassLoader erweitert ClassLoader nach den oben aufgelisteten Punkten. Die Class-Files werden dabei aus dem relativen Verzeichnis./store ausgelesen. Die darin enthaltenen Class-Files haben die Endung.impl (anstatt.class) um zu garantieren, dass sie nicht von der JVM geladen werden. Ist das Verzeichnis./store nicht im Klassenpfad (CLASSPATH) eingetragen, ist die Änderung der Endung nach.impl nicht nötig. public synchronized Class loadclass(string classname, boolean resolveit) throws ClassNotFoundException Class result; byte classdata[]; System.out.println(">>>>>> Load class : "+classname); /* Check our local cache of classes */ result = (Class)classes.get(className); if (result!= null) System.out.println(">>>>>> returning cached result."); Urs Frick Seite 8 von 28

9 return result; Der Codeabschnitt oben ist der Anfang der überladenen Methode loadclass. Im ersten Schritt wird überprüft, ob die verlangte Klasse bereits geladen wurde. Dadurch wird in der HashMap classes nach einem entsprechenden Eintrag gesucht. Die HashMap wird durch loadclass unterhalten. Wichtig ist, dass für den gleichen Klassennamen immer das gleiche Class Objekt zurückgegeben wird, andernfalls nimmt das System an, dass zwei unterschiedliche Klassen mit dem gleichen Namen bestehen. /* Check with the system class loader */ try result = findsystemclass(classname); System.out.println(">>>>>> returning system class (in CLASSPATH)."); return result; catch (ClassNotFoundException e) System.out.println(">>>>>> Not a system class."); An dieser Stelle ist der Aufruf von findsystemclass essentiell für die Sicherheit und Integrität des Systems. Durch findsystemclass wird versucht, die Klasse in der Java Library zu finden. Wird das nicht gemacht, könnte an dieser Stelle eine eigene Implementation von z.b. java.lang.object oder java.lang.securitymanager zurückgegeben werden. Das Laden einer dieser Klassen würde in einer Exception beim Aufruf von defineclass enden, da nur die Klassenlader der VM Klassen des Packages java.* laden dürfen. /* Try to load it from our repository */ classdata = getclassfrommyrepository(classname); if (classdata == null) throw new ClassNotFoundException(); Wenn an dieser Stelle noch keine Klasse gefunden werden konnte, so kann jetzt im eigenen Repository nach der Klasse gesucht werden. Dieser Vorgang wird durch den Aufruf der Methode getclassfrommyrepository symbolisiert. Der benutzerspezifische Klassenlader muss nun den Bytecode laden, der die verlangte Klasse repräsentiert. /* Define it (parse the class file) */ result = defineclass(classdata, 0, classdata.length); if (result == null) throw new ClassFormatError(); Die gefundene Klasse wird nun durch defineclass an die VM übergeben, welche nun aus dem Byte-Array ein Class Objekt erstellt. if (resolveit) resolveclass(result); classes.put(classname, result); System.out.println(">>>>>> Returning newly loaded class."); return result; Urs Frick Seite 9 von 28

10 Vor dem Rückgeben des Class Objekts muss die Klasse noch weiter aufgelöst werden, d.h. es muss dafür gesorgt werden, dass alle referenzierten Objekte in der Klasse auch geladen werden. Beim Zuweisen der neu geladenen Klasse ist folgendes zu beachten: c = scl.loadclass( A ); o = c.newinstance(); ((A)o).foo(); Wird dieser Code ausgeführt, so wird der System ClassLoader mit dem auch die main-klasse geladen wurde die Klasse A nicht finden, da diese ja in unserem eigenen Repository ist. Entsprechend muss hier über einen Basistyp, der beiden Klassenladern bekannt ist, gecastet werden. c = scl.loadclass( A ); o = c.newinstance(); ((Runnable)o).run(); Der Vollständige Code von SimpleClassLoader befindet sich im Anhang A 3. Klassenlader nach Java Delegation Model Wie bereits erwähnt hat sich für das Laden von Klassen mit Java 2 einiges geändert. Grund dafür war, dass das oben angegebene Schema eingehalten werden musste um keine unvorhergesehenen Fehler zu verursachen. In Java 2 wurde deshalb das Delegation Model für Klassenlader eingeführt. Dazu wurde die Methode findclass eingeführt und der Konstruktor von ClassLoader verlangt neu einen Parent Klassenlader. Der leere Konstruktor ruft dabei diesen Konstruktor mit dem System Klassenlader als Parameter auf. Vorgegeben wird nun, dass nicht mehr loadclass sondern findclass überschrieben wird. In loadclass wird nun nämlich wie im Beispiel [6] von SimpleClassLoader2 zuerst der Parent Klassenlader aufgerufen. Durch das Delegation Model erhält immer der oberste Klassenlader in der Hierarchie als erstes die Möglichkeit die entsprechende Klasse zu laden. Somit wird z.b. sichergestellt, dass die Klassen aus der Java Library von System ClassLoader geladen werden. Die Probleme, die auftreten können, wenn ein anderer Klassenlader Standardklassen lädt, wurden oben bereits erwähnt. Die Methode loadclass kann natürlich immer noch überschrieben werden, um das Verhalten des Klassenladers den eigenen Anforderungen entsprechend anzupassen. Zu beachten ist aber, dass die Typensicherheit eingehalten wird Exkurs: Delegation Pattern Das Delegation Pattern [11] simuliert Vererbung durch Komposition. Dabei wird von einem empfangenden Objekt eine Operation auf einem Delegationsobjekt ausgeführt. Dies korrespondiert mit der Vererbung beim Aufruf einer Operation auf der super-klasse. Urs Frick Seite 10 von 28

11 Am Beispiel einer Fensterklasse können so rechteckspezifische Operationen an die Rechteckklasse delegiert werden. Die Fensterklasse muss dazu eine Referenz auf eine Rechteckklasse haben. Fenster Fläche() Rechteck Rechteck Fläche() breite höhe return rechteck ->Flaeche() return breite * höhe Der Vorteil des Delegation-Patterns besteht darin, dass die Vererbungsstrukturen zur Laufzeit erstellt werden können und somit nicht statisch sind Beispiel SimpleClassLoder2.java Wie bereits beschrieben soll zum bereitstellen der Klasse nur noch findclass überschrieben werden. loadclass ist ab Java 2 deshalb auch nicht mehr abstract definiert sondern ruft nach der erfolglosen Delegation an den Parent Klassenlader die Methode findclass auf. Implementation von loadclass in Java 2 protected synchronized Class loadclass(string name, boolean resolve) throws ClassNotFoundException // First, check if the class has already been loaded Class c = findloadedclass(name); if (c == null) try if (parent!= null) c = parent.loadclass(name, false); else c = findbootstrapclass0(name); catch (ClassNotFoundException e) // If still not found, then invoke findclass in order // to find the class. c = findclass(name); if (resolve) resolveclass(c); return c; Urs Frick Seite 11 von 28

12 findclass ist dann für das Suchen der Klasse verantwortlich. In dieser Methode muss der Bytecode für die gewünschte Klasse geladen werden. Anschliessend wird defineclass aufgerufen, dass eine Class Objekt zurückliefert. Nachfolgend die überschriebene findclass Methode für das Beispiel SimpleClassLoader2.java. protected Class findclass(string name) throws ClassNotFoundException FileInputStream fi = null; try System.out.println("SimpleClassLoader2 finding class: " + name); String path = name.replace('.', '/'); fi = new FileInputStream("store/" + path + ".impl"); byte[] classbytes = new byte[fi.available()]; fi.read(classbytes); return defineclass(name, classbytes, 0, classbytes.length); Im Codebeispiel ist ersichtlich, dass die Methode findclass nur noch für das laden des Bytecodes und für den Aufruf von defineclass verantwortlich ist. Auch hier wird wie beim SimpleClassLoader1 vom relativen Verzeichnis./store aus nach Klassen mit der Dateiendung.impl gesucht. Wird das File gefunden, wird ein FileInputStream geöffnet und das gelesene Byte-Array an defineclass übergeben. Treten dabei keine Fehler auf, wird die von defineclass zurückgelieferte Klasse zurückgegeben. Anstatt das Class-File umzubenennen könnte man auch dafür sorgen, dass es nicht auf dem Klassenpfad (CLASSPATH) liegt und somit nicht vom System Klassenlader gefunden wird. findclass müsste natürlich das File noch finden können. Der Vollständige Code zu SimpleClassLoader2 ist im Anhang B. 4. Klassenlader in der JVM Wie im Punkt Delegation Model beschrieben, wurde in Java 2 das Model des Klassenladers verändert. Der Klassenlader spielt eine zentrale Rolle beim Laden von Klassen und somit auch beim Starten von Applikationen. Entsprechend sind auch in die JVM Klassenlader eingebettet, die das Starten der JVM an sich und anschliessend das Starten von Applikationen ermöglichen. Wann immer in Java Klassen geladen werden, muss zuerst an den Parent Klassenlader delegiert werden. In Java ergibt das eine Struktur von drei Klassenladern, die beim starten jeder Applikation benötigt werden. Namentlich sind das Bootstrap-, Extension- und System- (oder Application) Klassenlader Bootstrap Klassenlader Der Bootstrap Klassenlader hat keinen Typ, d.h. er ist nicht von ClassLoader abgeleitet. Er stellt einen speziellen Klassenlader dar, da er direkt in die VM implementiert ist und ist somit nativer Code. Der Bootstrap Klassenlader hat keinen Parent und ist somit oberster Klassenlader in der Klassenladerhierarchie. Durch das Delegation Model wird somit versucht jede Klasse zuerst mit dem Bootstrap Klassenlader zu laden. Urs Frick Seite 12 von 28

13 Der Bootstrap Klassenlader ist dafür verantwortlich die Klassen der Java Standard-Library zu laden. Definiert wird der Ort der Standardlibrary durch das Property sun.boot.class.path Extension Klassenlader Der Extension Klassenlader ist vom Typ sun.misc.lanucher$extclassloader. Der Parent dieses Klassenladers ist der Bootstrap. Der Extension Klassenlader wurde in Java mit dem Konzept der Extensions eingeführt. Er lädt Klassen aus dem Verzeichnis gegeben durch das Property java.ext.dirs. Per Default liegt dies in JAVA_HOME/rte/lib/ext 4.3. System (oder Application) Klassenlader Der System Klassenlader ist vom Typ sun.misc.launcher$appclassloader. Der Parent dieses Klassenladers ist der Extension Klassenlader. Der System Klassenlader lädt die Klassen, die sich auf dem Klassenpfad (CLASSPATH) befinden. Der Klassenpfad wird auch durch das Property java.class.path definiert. Es kann jederzeit eine Referenz auf diesen Klassenlader über ClassLoader.getSystemClassLoader verlangt werden Beispiel: Class.forName() Das folgende Beispiel [2] soll das Zusammenspiel der verschiedenen Klassenlader veranschaulichen. Zu beachten ist, dass Class.forName() die Methode loadclass auf dem aktuellen Klassenlader aufruft. public class DynamicLoader public static void main(string[] args) throws Exception System.out.println("DynamicLoader run: \""+args[0] +"\"["+DynamicLoader.class.getClassLoader()+"]"); // 1 // // Load class with definig class loader Class torun = Class.forName("Echo"); Runnable r = (Runnable)toRun.newInstance(); r.run(); Aufruf von DynamicLoader über die Konsole: java DynamicLoader Echo DynamicLoader run: "Echo" [sun.misc.launcher$appclassloader@e80a59] ClassLoader of torun:sun.misc.launcher$appclassloader@e80a59 Echo [sun.misc.launcher$appclassloader@e80a59] Wie in der Konsolenausgabe ersichtlich ist, wird die Klasse Echo gefunden und geladen. Ersichtlich ist auch, dass die beiden Klassen DynamicLoader und Echo vom System Klassenlader geladen wurden. Urs Frick Seite 13 von 28

14 Als nächsten Schritt wollen wird den Beispielcode von DynamicLoader in ein Package speichern und als Extension starten. Nach dem erstellen des JAR wird das File also in das Verzeichnis JAVA_HOME/rte/lib/ext kopiert. Zu beachten ist, dass nur DynamicLoader in das JAR kopiert wird. Die Klasse Echo bleibt im Klassenpfad. Aufruf von DynamicLoader über die Konsole, gestartet als Extension: java DynamicLoader Echo DynamicLoader run: "Echo" java.lang.classnotfoundexception: Echo at java.net.urlclassloader$1.run(unknown Source) at java.security.accesscontroller.doprivileged(native Method) at java.net.urlclassloader.findclass(unknown Source) at java.lang.classloader.loadclass(unknown Source) at java.lang.classloader.loadclass(unknown Source) at java.lang.classloader.loadclassinternal(unknown Source) at java.lang.class.forname0(native Method) at java.lang.class.forname(unknown Source) at DynamicLoader.main(DynamicLoader.java:11) Exception in thread "main" Obwohl die Klasse Echo im Klassenpfad liegt, wird Echo nicht gefunden. Das Problem ist dabei im Delegation Model zu suchen. Wird das Programm nicht als Extension gestartet so bewirkt der Aufruf von Class.forName(), dass der System ClassLoader, der die Main Klasse aufgelöst hat, zuerst an seinen Parent delegiert. Somit sucht zuerst Bootstrap ClassLoader und anschliessend der Extension ClassLoader vergebens nach der Klasse Echo. Erst wenn die Verantwortung zurück zum System Klassenlader zurückkehrt wird dieser auf dem Klassenpfad fündig. Beim Ausführen als Extension delegiert der System Klassenlader zuerst an den Extension Klassenlader und dieser wiederum an den Bootstrab Klassenlader. Der Bootstrap Klassenlader wird die Klasse DynamicLoader nicht finden. Somit erhält der Extension Klassenlader die Chance die Klasse zu laden. Natürlich findet der Extension Klassenlader die Klasse DynamicLoader im Extension Verzeichnis des Runtime-Environments. Somit ist der Extension Klassenlader für das Laden der ausführenden Klasse verantwortlich. Wird nun versucht mit Class.forName() die Klasse Echo zu laden, so ist der Extension Klassenlader der Lader, der das Laden delegiert. Der Bootstrap als Parent scheitert bei der Suche und übergibt die Verantwortung wieder an den Extension Klassenlader, welcher auch scheitert. Echo liegt nämlich auf dem Klassenpfad und kann deshalb nur durch den System ClassLoader gefunden werden, welcher in diesem Model aber gar nie die Gelegenheit erhält Echo zu suchen Lösungen zu Beispiel Class.forName() Um das Problem zu Lösen, muss Echo über den System Klassenlader geladen werden. DynamicLoader muss also loadclass auf dem System Klassenlader aufrufen. Um an den System Klassenlader zu kommen gibt es zwei verschiedene Wege: Urs Frick Seite 14 von 28

15 Thread.getContextClassLoader() Dies ist ein neues Konzept, dass auch in Java 2 neu eingeführt wurde. getcontextclassloder liefert den Klassenlader des Threadkontexts zurück. Über setcontextclassloader kann der Parent des Threads den Kontextklassenlader des Threads setzten. Wird keine Klassenlader gesetzt, so wird der Kontextklassenlader des Parent-Threads gesetzt. Der Kontextklassenlader des main-threads ist typischerweise der System Klassenlader. public static void main(string[] args) throws Exception // 2 // Class torun = Thread.currentThread().getContextClassLoader().loadClass(args[0]); System.out.println("ClassLoader oftorun:"+ torun.getclassloader()); Method mainmethod = findmain(torun); mainmethod.invoke(null, new Object[]new String[0]); Argumente-Form von Class.forName() Die zweite Möglichkeit besteht darin die 3 parametrige Form von Class.forName() aufzurufen. Bei dieser Form kann als dritter Parameter ein Klassenlader übergeben werden. Über die statische Methode ClassLoader.getSystemClassLoader() bekommen wird den System Klassenlader und können Echo so laden. public static void main(string[] args) throws Exception // 3 // Class torun = Class.forName(args[0],true,ClassLoader.getSystemClassLoader()); System.out.println("ClassLoader of torun:"+torun.getclassloader()); Method mainmethod = findmain(torun); mainmethod.invoke(null, new Object[]new String[0]); Die Ausgabe auf der Konsole der zwei beschriebenen Lösungen: java DynamicLoader Echo DynamicLoader run: "Echo" [sun.misc.launcher$extclassloader@1ff5ea7] ClassLoader of torun:sun.misc.launcher$appclassloader@e80a59 Echo [sun.misc.launcher$appclassloader@e80a59] Der gesamte Source-Code zu DynamicLoader ist im Anhang C. 5. Multiple Klassenlader Java Applikationen können mit mehreren Klassenladern mehrere Komponenten verwalten, welche von verschiedenen Quellen stammen können. Die einzelnen Komponenten sind dabei voneinander unabhängig, greifen aber auf gleiche Ressourcen zu. Am Beispiel von Applets lässt sich dies besonders gut erklären. Für jedes Applet wird ein separater Klassenlader initialisiert. Der Code der einzelnen Applets ist voneinander unabhängig. Die Java Library Klassen werden allerdings von allen Applets geteilt. Dies ist Urs Frick Seite 15 von 28

16 durch das Delegation Model möglich. Die einzelnen Klassenlader der Applets verwalten die Appletklassen, delegieren das Laden von Systemklassen aber dem System Klassenlader Namespaces Das Delegieren des Ladens von Klassen ermöglicht es uns verschiedene Namensräume zu unterhalten. So können z.b. in einem Browser zwei verschiedene Applets geladen werden die beide HelloWorldApplet heissen (diese Konstellation dürfte nicht all zu unwahrscheinlich sein). Dieser Umstand wird dadurch ermöglicht, dass in der VM Klassen nicht nur durch ihren Namen (Package und Klassenname) unterschieden werden, sondern auch dadurch, durch welchen Klassenlader die entsprechenden Klassen geladen wurden. In unserem Beispiel wird für jedes Applet ein separater URLClassLoader initialisiert. Klassen wie java.lang.string werden dabei an den System Klassenlader delegiert, während die Applet-Klassen durch den URLClassLoader geladen werden. Dies gewährt auch Typensicherheit, d.h. ein Applet ist es somit nicht möglich eine eigene Implementation von java.lang.securitymanager zur Verfügung zu stellen Beispiel: Multiple Klassenlader Die Nachfolgende EchoImpl Klasse definiert eine Methode, die den Stand des statischen Zählers ausgibt und erhöht. Das Interface Echo stellt nur die Methode echo() zur Verfügung. Die Endung der Klasse EchoImpl wird für dieses Beispiel von.class nach.impl umbenannt. public class EchoImpl implements Echo static int counter = 0; public void echo() System.out.println("Echo: "+(counter++)+ "["+(EchoImpl.class.getClassLoader())+" ]"); Die nachfolgende Klasse Driver initialisiert zweimal die gleiche Instanz der Klasse FileClassLoader. Für diesen Klassenlader ist nur zu bemerken, dass er ein Class-File mit der Endung.impl laden kann. Die Endung.impl dient dazu, dass das Class-File von keinem anderen Klassenlader gefunden wird. Anschliessend werden zwei Instanzen der Klasse EchoImpl geladen und nach Echo gecastet. Die Aufrufe der Methode echo() auf den beiden Instanzen verdeutlichen, dass die statische Zählervariable der Klasse nicht von den beiden Instanzen geteilt wird. Für die VM gibt es also zwei verschiedene Klasen Echo mit dem gleichen Namen. Der Unterschied macht die VM bei der Referenz der Klassen auf den Klassenlader. public class Driver public static void main(string[] args) throws MalformedURLException, InstantiationException, IllegalAccessException, ClassNotFoundException //define two instances of the same classloader FileClassLoader l1 = new FileClassLoader(); FileClassLoader l2 = new FileClassLoader(); //get two instances from the same class with two different //class laoders Urs Frick Seite 16 von 28

17 Echo e1 = (Echo)l1.loadClass("EchoImpl").newInstance(); Echo e2 = (Echo)l2.loadClass("EchoImpl").newInstance(); //EchoImpl e1 (EchoImpl)l1.loadClass("EchoImpl").newInstance(); //results in a exception because system classloader does not //find EchoImpl //check echo of both eco instances e1.echo(); e1.echo(); e1.echo(); e2.echo(); Konsolenausgabe: Echo: 0 [FileClassLoader@defa1a ] Echo: 1 [FileClassLoader@defa1a ] Echo: 2 [FileClassLoader@defa1a ] Echo: 0 [FileClassLoader@107077e ] 5.2. Typensicherheit Die loadclass Methode eines benutzerdefinierten Klassenladers könnte verschiedene Typen für einen gegebenen Klassennamen bereitstellen. Um Typensicherheit zu gewähren muss die JVM garantieren können, dass für einen gegebenen Klassennamen der richtige Typ zurückgeliefert wird. class C void f(x x) void g() f(new X()); Würden im obigen Codeausschnitt die beiden Klassen X zu verschiedenen Klassen gemapt, so würde das System inkonsistent werden. Der Lösungsansatz der VM besteht darin, dass sie keinem Klassenlader vertraut. Zu diesem Zweck führt die VM einen Loaded-Class-Cache. In diesem Cache werden Klassenname und initialisierender Klassenlader gemapt. Wird eine Klasse über loadclass geladen wird folgendes ausgeführt: Der Name der Klasse, der im Class-File definiert ist, wird mit dem an loadclass übergebenen Namen verglichen. Stimmen die beiden Klassennamen nicht überein, so wird eine Exception ausgelöst. Stimmen die Klassennamen überein, so wird der Klassenname mit dem initialisierenden Klassenlader in den Loaded-Class-Cache eingetragen. Die VM ruft die Methode loadclass dabei nur einmal für den gleichen Klassennamen auf. An dieser Stelle sei noch erläutert, dass eine Klasse einen initialisierenden und einen definierenden Klassenlader hat. Initialisierender und definierender Klassenlader können dabei ein und derselbe Klassenlader sein: Definition: Urs Frick Seite 17 von 28

18 C sei das Resultat von L.defineClass(). L ist somit der definierende Klassenlader von C. C sei das Resultat von L.loadClass(). L ist somit initialisierender Klassenlader von C Typensicherheit bei Delegation Nachfolgend soll noch erläutert werden, welche Problem beim delegierten Laden von Klassen auftreten können. An dieser Stelle soll folgende Notation 2 eingeführt werden. Notation: <C,L d > Li C: Name der Klasse L d : Definierender Klassenlader L i : Initialisierender Klassenlader Wird nur <C,Ld> angegeben, wird damit ausgedrückt, dass der initialisierende Klassenlader nicht von Bedeutung ist. Umgekehrt wird bei der Angabe C Li nur angegeben, dass C durch Li initialisiert wurde Problem Anschließend wird an einem Beispiel beschrieben, welche Probleme beim Laden von Klassen nach Delegation Model auftreten können. Zu diesem Zweck gehen wir von folgendem Codebeispiel aus: class C void f() Spoofed x = new Delegated().g(); class Delegated Spoofed g() Gehen wir nun davon aus, dass die Klassen C, Delegated und Spoofed von verschiedenen Klassenladern L1 und L2 geladen werden können und verwenden zur Darstellung des Problems die oben eingeführt Notation: class <C,L1> void f() <Spoofed, L 1 > L1 x = <Delegated, L 2 > L1.g(); class <Delegated, L 2 > <Spoofed, L 2 > L2 g() Die Klasse C wird durch den Loader L1 geladen und aufgelöst. Dadurch wird veranlasst, dass Spoofed durch L1 definiert wird. Weiter delegiert L1 die Klasse Delegated an Loader L2. Somit ist auch Loader L2 für das Auflösen der Klasse Delegate verantwortlich. 2 Die Notation wird im Bericht von Sheng Liang und Gilad Bracha [1] verwendet. Urs Frick Seite 18 von 28

19 Dies führt dazu, dass Loader L2 einen eigenen Typ von Spoofed definiert. Da C beim Aufruf von <Delegated, L2>.g() eine Rückgabe vom Typ <Spoofed, L1> erwartet, durch Delegate aber ein <Spoofed, L2> zurückgeliefert wird, entsteht eine Inkonsistenz zwischen den beiden Namensräumen der beiden Klassenlader Lösung Ein Lösungsansatz besteht darin zu kontrollieren ob ein Typ vom gleichen Klassenlader definiert wird, indem die Klasse von allen möglichen Ladern geladen wird. Spoofed müsste also von L1 und von L2 initialisiert werden, anschliessend kann kontrolliert werden, ob es sich um den gleichen Typ handelt. Dadurch wird allerdings das Lazy-Loading 3 nicht mehr gewährleistet. Java löst dieses Problem deshalb auf eine andere Art. Es werden zu diesem Zweck Bedingungen (Constraints) eingeführt. Die Constraints werden in einem Cache verwaltet. Im obigen Beispiel würde also ein Constraint entstehen das besagt: Spoofed L1 = Spoofed L2. Wenn Spoofed nun später geladen wird, wird kontrolliert, ob das Constraint nicht verletz wird. Es besteht allerdings auch die Möglichkeit, dass Spoofed L1 und Spoofed L2 bereits geladen sind und das Constraint erste danach eingeführt wird. Es ergeben sich daraus folgende Regel: Immer wenn ein neuer Eintrag in den Loaded-Class-Cache gemacht wird, wird kontrolliert, ob kein Constraint verletzt wurde. Andernfalls schlägt dass Laden der Klasse fehl. Immer wenn ein neues Constraint hinzugefügt wird, wird kontrolliert ob alle geladenen Klassen das Constraint erfüllen. Andernfalls schlägt das Hinzufügen des Constraints fehl. An unserem Beispiel erstellt die die VM, durch die Zeile wo die Methode C.f() aufgerufen wird, das Constraint Spoffed L1 = Spoofed L2. Wird nun Spoofed L2 geladen wird eine Exception ausgelöst, da Spoffed L1 = Spoofed L2 nicht vom gleichen Typ sind und somit das Constraint verletzt wird. Für die VM ergibt sich dadurch ein Regelwerk, das nachfolgend aufgelistet wird: <C,L1> referenziert ein Feld: T name; deklariert in <D, L2>, dann wird folgendes Constraint hinzugefügt: T L1 = T L2 <C,L1> referenziert eine Methode: T0 methodenname(t1, T2,, Tn) deklariert in <D,L2>, dann wird folgendes Constraint hinzugefügt: T0 L1 = T0 L2, T1 L1 = T1 L2,, Tn L1 = Tn L2 3 Das Lazy-Loading Konzept besagt, dass Klassen erste geladen werden, wenn sie benötigt werden. Beim ausführen einer kleinen Java Applikation ist es deshalb nicht nötig die ganze Java Library zu laden, sondern nur jene Klassen, die effektiv benötigt werden. Urs Frick Seite 19 von 28

20 <C,L1> überschreibt eine Methode: T0 methodenname(t1, T2,, Tn) deklariert in <D,L2>, dann wird folgendes Constraint hinzugefügt: T0 L1 = T0 L2, T1 L1 = T1 L2,, Tn L1 = Tn L2 Wird irgendeine dieser Regeln zur Laufzeit verletzt, so wird ein java.lang.linkageerror ausgelöst. Die Constraints werden vom Cache gelöscht, sobald der korrespondierende Klassenlader vom Garbage-Collector abgeräumt wurde. 6. Anwendungen Nachfolgend soll eine Übersicht über konkrete und mögliche Anwendungen mit Klassenlader gegeben werden. Es soll dabei veranschaulicht werden, wie wichtig und verbreitet Klassenlader sind Server Applikationen am Beispiel von Apache Tomcat Bei Server Applikationen ist der Aspekt von verschiedenen Namensräumen besonders wichtig, insbesondere dann wenn der Server kommerziell genutzt werden kann. Auch das dynamische Laden von Klassen spielt hierbei eine wichtige Rolle um z.b. nur einzelnen Webapplikationen neu starten zu können ohne dabei den ganzen Server zu rebooten. Der Apache Tomcat tritt mit einer ganzen Sammlung von Klassenladern auf. Bootstrap VM Klassenlader System Common Catalina Shared Webapp 1 Webapp 2 Der Common Klassenlader lädt klassen, die für interne Klassen des Tomcat und für alle Webapplikationen zur Verfügung stehen müssen. Die Quelle für den Common Klassenlader ist: $CATALINA_HOME/common/classes. Der Catalina Klassenlader ist für das Laden der Serverklassen verantwortlich. Diese Klassen sind somit vollkommen unsichtbar für Webapplikationen. Der Shared Klassenlader ist für das Laden von Klassen verantwortlich, die für alle Webapplikationen zur Verfügung stehen sollen. Schlussendlich wird eine Vielzahl von Webapp Klassenladern für das Laden der verschiedenen Webapplikationen verantwortlich sein. Jede Webapplikation hat somit ihren eigenen Namensraum und kann auf Klassen zugreifen, die von den Shared, Common und System Klassenladern bereitgestellt werden. Urs Frick Seite 20 von 28

21 Der Webapp Klassenlader weicht vom Java 2 Delegation Model für Klassenlader ab. Nach der Servlet Spezifikation Version 2.3 versucht der Webapp Klassenlader zuerst im Verzeichnis der Webapplikation die angeforderten Klassen zu finden. Erst danach delegiert der Webapp Klassenlader an den Shared Klassenlader weiter. Um damit kein Sicherheitsrisiko zu verursachen lehnt es der Webapp Klassenlader ab Java Library-Klassen (java.*) zu laden. Es ist durch den Webapp Klassenlader auch möglich nur einzelnen Webapplikationen neu zu laden Sicherheit Klassenlader könnten auch dazu verwendet werden eigene Sicherheitsrisiken zu verhindern. So könnten z.b. digitale Signaturen in Klassen verwendet werden, die geprüft werden müssen, bevor eine Klasse geladen und ausgeführt werden darf. Es könnten auch eigene Sandbox Regeln definiert werden. Klassenlader könnten beim Laden der Klassen kontrollieren ob eine Klasse die Sandbox Regeln brechen würde Verschlüsselung / Entschlüsselung von Klassen Klassenlader könnten auch dazu dienen Javacode zu verschlüsseln. Und entsprechenden Code on the fly wieder zu entschlüsseln. Wertvoller Code könnte so von Dekompilern geschützt werden und müsste nicht in zusätzlichen Schritten entschlüsselt werden Archivierung Soll Java Code in einem speziellen Format oder in einer speziellen Kompression zur Verfügung gestellt werden, so müssen entsprechende Klassenlader erstellt werden. Klassen könnten z.b. auch in einem Archiv-File abgelegt werden, in dem mehrere Versionen eines Packages abgelegt sind. Der Klassenlader ist anschliessend verantwortliche die Klassen zur gewünschten Version zu laden 6.5. Selbst-Extrahierende Programme Es ist möglich eine vollständige Java Applikation in ein einziges ausführbares Class-File zu kompilieren, welches weitere Class-Files enthält zusammen mit einem integralen Klassenlader, der die Klassen aus dem entsprechenden Fiel wieder extrahieren kann Dynamisches generieren von Klassen Klassen können mit Klassenlader zur Laufzeit generiert und definiert werden. Dies findet unter anderem bei JSP Anwendung. JSP-Seiten werden zuerst geparst und in kompilierbare Java-Files umgesetzt. Anschliessend werden sie kompiliert und vom Webapp Klassenlader geladen Ausblick auf das Application Isolation API Im JSR 121 (Java Specification Request) wird das Isolation API spezifiziert. Das API soll es ermöglichen mehrere Java Applikationen auf einer VM laufen zu lassen und dabei einige Kontrollmechanismen zur Verfügung stellen. Urs Frick Seite 21 von 28

22 Die Spez. schreibt dabei keine genaue Implementation vor. Das API muss lediglich die Isolation von Java State garantieren (z.b. logisch getrennte Heaps, statische Felder, etc.). Das API soll dabei mit der Klasse Isolation eine Schnittstelle bereitstellen, mit welcher Applikationen gestartet und kontrolliert werden können. Die Java Klassenlader wären hier ein möglicher Lösungsansatz, da sie durch ihre Namensräume eine Isolation ermöglichen würden. In Kombination mit Threads währe auch das Multitasking gewährleistet. Trotzdem würden einige Teile des JVM Kontexts geteilt werden und dies währe in diesem Fall inadäquat. Einige Teile des Java States würden so geteilt werden, was nicht immer transparent ist. Dies führt zu mehreren Szenarien, welche das Verwenden von Klassenladern wahrscheinlich ausschliesst. Urs Frick Seite 22 von 28

23 Quellenverzeichnis [1] Sheng Liang, Gilad Bracha. Dynamic Class Loading in the Java Virtual Machine. [2] Understanding the Java ClassLoader. IBM developerworks. [3] Ted Neward. Understanding Class.forName(). JavaGeeks.com White Paper. [4] JDC Tech Tips: October 31, [5] Chuck McManis. The basic of Java class loaders. [6] Ken McCrary. Create a custom Java 1.2-style ClassLoader. [7] Jack Harich. Java Tip 39: The trick to using a basic Java 1.1 network and file class loader. [8] Kevin Pauli. A ZipClassLoader for automated application distribution. [9] The Tomcat 4 Servlet/JSP Container. [10] Pete Soper. JSR 121 Application Isolation API Specification. [11] Erich Gamma et. al. (1995). Design Patterns; elements of reusable object-oriented software. Addison-Wesley. Urs Frick Seite 23 von 28

24 Anhang A: SimpleClassLoader1 import java.io.fileinputstream; import java.util.hashtable; /** * SimpleClassLoader1 is a code sample to show the mechanism of * class loading conform to java version 1.1 (and earlyer). */ public class SimpleClassLoader1 extends ClassLoader /** Chache for loaded classes */ private Hashtable classes = new Hashtable(); /** * This sample function for reading class implementations reads * them from the local file system */ private byte getclassfrommyrepository(string classname)[] System.out.println(">>>>>> Fetching the implementation of"+classname); byte result[]; try FileInputStream fi = new FileInputStream("store/"+className+".impl"); result = new byte[fi.available()]; fi.read(result); return result; catch (Exception e) /* * If we caught an exception, either the class wasnt found or it * was unreadable by our process. */ return null; /** * This is a simple version for external clients since they * will always want the class resolved before it is returned * to them. */ public Class loadclass(string classname) throws ClassNotFoundException return (loadclass(classname, true)); /** * This is the required version of loadclass which is called * both from loadclass above and from the internal function * FindClassFromClass. */ public synchronized Class loadclass(string classname, boolean resolveit) throws ClassNotFoundException Class result; byte classdata[]; System.out.println(">>>>>> Load class : "+classname); /* Check our local cache of classes */ result = (Class)classes.get(className); Urs Frick Seite 24 von 28

25 if (result!= null) System.out.println(">>>>>> returning cached result."); return result; /* Check with the primordial class loader */ try result = findsystemclass(classname); System.out.println(">>>>>> returning system class " +"(in CLASSPATH)."); return result; catch (ClassNotFoundException e) System.out.println(">>>>>> Not a system class."); /* Try to load it from our repository */ classdata = getclassfrommyrepository(classname); if (classdata == null) throw new ClassNotFoundException(); /* Define it (parse the class file) */ result = defineclass(classdata, 0, classdata.length); if (result == null) throw new ClassFormatError(); if (resolveit) System.out.println(">>>>>> Resolve class"); resolveclass(result); classes.put(classname, result); System.out.println(">>>>>> Returning newly loaded class."); return result; public static void main(string args[]) throws InstantiationException, IllegalAccessException, ClassNotFoundException SimpleClassLoader1 loader = new SimpleClassLoader1(); Runnable r = (Runnable)loader.loadClass("Echo",false).newInstance(); r.run(); /* * Echo just prints out Echo and defining class loader when initialized */ public class Echo implements Runnable public void run() System.out.println("Echo ["+Echo.class.getClassLoader()+"]"); Urs Frick Seite 25 von 28

26 Anhang B: SimpleClassLoader2.java import java.io.fileinputstream; /** * Simple class loader to illustrate custom Class loading * with new delegation * model in Java 1.2. */ public class SimpleClassLoader2 extends ClassLoader /** * Provide delegation constructor */ SimpleClassLoader2(ClassLoader parent) super(parent); /** * Same old ClassLoader constructor */ SimpleClassLoader2() super(); /** * This is the method where the task of class loading is * delegated to ourcustom loader. * */ protected Class findclass(string name) throws ClassNotFoundException FileInputStream fi = null; try System.out.println("SimpleClassLoader2 finding class: " + name); String path = name.replace('.', '/'); fi = new FileInputStream("store/" + path + ".class"); byte[] classbytes = new byte[fi.available()]; fi.read(classbytes); return defineclass(name, classbytes, 0,classBytes.length); catch (Exception e) // We could not find the class, so indicate the problem with an // exception throw new ClassNotFoundException(name); finally if (null!= fi) try fi.close(); catch (Exception e) Urs Frick Seite 26 von 28

27 public static void main(string args[]) throws InstantiationException, IllegalAccessException, ClassNotFoundException SimpleClassLoader2 loader = new SimpleClassLoader2(); Runnable r = (Runnable) loader.loadclass("echo").newinstance(); r.run(); /* * Echo just prints out Echo and defining class loader when initialized */ public class Echo implements Runnable public void run() System.out.println("Echo ["+Echo.class.getClassLoader()+"]"); Urs Frick Seite 27 von 28

28 Anhang C: DynamicLoader, Echo /* * Code example to illustrate delegation betwen bootstrap, extension * and system class loader. */ public class DynamicLoader public static void main(string[] args) throws Exception System.out.println("DynamicLoader run: \""+args[0]+"\" [" +DynamicLoader.class.getClassLoader()+"]"); // 1 // // Load class with definig class loader Class torun = Class.forName("Echo"); // 2 Extension solution 1 // // load class with context class loader from current thread //Class torun = // Thread.currentThread().getContextClassLoader().loadClass("Echo"); // 3 Extension solution 2 // // load class with system class loader // Class torun = // Class.forName("Echo",true,ClassLoader.getSystemClassLoader()); Runnable r = (Runnable)toRun.newInstance(); r.run(); /* * Echo just prints out Echo and defining class loader when initialized */ public class Echo implements Runnable public void run() System.out.println("Echo ["+Echo.class.getClassLoader()+"]"); Urs Frick Seite 28 von 28