Java Reference
In-Depth Information
dem Namen hotdeployment angelegt werden. Dahin müssen die Class-Dateien für die
Klassen HotDeploymentClass1 und HotDeploymentClass2 verschoben werden. Aber bitte
beachten Sie, dass sich in diesem Verzeichnis — wie auch in bin — eine Verzeichnisstruktur
befi nden muss, die der Package-Struktur entspricht. Für den vorliegenden Fall heißt das,
dass in hotdeployment ein Verzeichnis namens javacomp, darin ein Verzeichnis basics und
darin die Class-Dateien sein müssen.
Wenn diese Struktur hergestellt wurde, kann das obige Programm ausgeführt werden. Nun
kann im laufenden Betrieb die Ausgabe in der Methode call der Klasse HotDeployment-
Class1 geä ndert werden. Anschließend muss logischerweise die aus der Übersetzung resul-
tierende Class-Datei wieder unter hotdeployment abgespeichert werden. Dann wird beim
nächsten Schleifendurchlauf diese neue Klassenversion geladen und man sieht die verä n-
derte Ausgabe, ohne dass die Programmausführung zwischendurch gestoppt wurde.
Interessanterweise funktioniert dies auch für die Klasse HotDeploymentClass2. Das heißt:
Wenn man die Ausgabe in der Methode call der Klasse HotDeploymentClass2 ändert, dann
sieht man diese Änderung ebenfalls im laufenden Betrieb, obwohl diese Klasse nicht expli-
zit durch den neuen ClassLoader geladen wird. Das wird sie aber implizit doch wegen des
am Ende des vorigen Abschnitts geschilderten Sachverhalt: Da HotDeploymentClass2 in
HotDeploymentClass1 benutzt wird, wird HotDeploymentClass2 von demselben ClassLoa-
der geladen, der HotDeploymentClass1 geladen hat. Egal, ob man nur eine der beiden oder
beide Klassen ändert; man sieht den Eff ekt beim nächsten Schleifendurchlauf. Wenn die
Klassen allerdings zwischendurch in den CLASSPATH geraten und von dort geladen wer-
den, dann ist ab diesem Zeitpunkt kein Laden einer neuen Version mehr möglich, selbst
wenn man die Class-Dateien wieder aus dem CLASSPATH nimmt und im Verzeichnis hot-
deployment eine neue Version ablegt. Denn bei jedem Laden über einen neuen ClassLoader
werden zuerst die übergeordneten ClassLoader aufgefordert, die Klasse zu laden. Da einer
von diesen die Klasse zuvor schon erfolgreich geladen hat, meldet dieser ClassLoader Erfolg
und das Laden ist beendet; auf die neue Klassenversion erfolgt kein Zugriff mehr.
5 . 3 . 2 Gleichzeitige Nutzung mehrerer Versionen einer Klasse
In dem vorhergehenden Beispiel wurde immer nur die jeweils aktuellste Version der beiden
Klassen verwendet. Das Objekt, das im vorhergehenden Schleifendurchlauf zu einer even-
tuell anderen Klassenversion erzeugt wurde, wird vergessen und ist im nächsten Schleifen-
durchlauf nicht mehr verfügbar. In einem weiteren Beispielprogramm soll deshalb demons-
triert werden, dass es gleichzeitig mehrere Objekte unterschiedlicher Klassenversionen
derselben Klasse geben kann. Dieses Beispiel geht über die Demonstration für Hot Deploy-
ment hinaus. Es soll ergänzend der Vorstellung entgegenwirken, dass es zu einem Zeit-
punkt immer nur eine Version einer Klasse in einem ausgeführten Programm geben könnte.
Es ist vielmehr so, dass eine Klasse eindeutig durch ihren vollständigen Klassennamen und
das ClassLoader-Objekt, das sie geladen hat, identifi ziert wird. Wenn also eine Klasse mit
einem bestimmten Namen von unterschiedlichen ClassLoader-Objekten geladen wird, dann
sind das für die JVM (Java Virtual Machine) unterschiedliche Klassen. Dabei kommt es nicht
darauf an, ob diese unterschiedlichen Klassen, die alle denselben Klassennamen haben,
tatsächlich unterschiedlich sind bezüglich des Programmcodes bzw. der Class-Datei oder
