Java Reference
In-Depth Information
■
4 . 2 Erzeugung dynamischer Proxies
mit Refl ection
Mit Hilfe der Refl ection-Bibliothek kann eine Klasse zur Laufzeit generiert werden, die eine
oder mehrere vorgegebene Java-Schnittstellen implementiert. Voraussetzung dafür ist logi-
scherweise, dass solche Schnittstellen vorhanden sind (im Gegensatz dazu benötigt man zur
Erzeugung von Klassen mit Hilfe der CGLIB keine Java-Schnittstellen, wie im folgenden
Abschnitt zu sehen sein wird). Zu einer dynamisch erzeugten Dynamic-Proxy-Klasse existiert
weder eine Java- noch eine Class-Datei, sondern das Class-Objekt und der Bytecode existieren
nur temporär in der JVM (Java Virtual Machine), also nur im Adressraum des Java-Prozesses.
Wenn eine Klasse erzeugt wird, die eine oder mehrere Schnittstellen implementiert, besitzt
sie logischerweise eine Menge von Methoden. Es stellt sich nun die Frage, was diese Metho-
den tun, d. h. welcher Code für diese Methoden generiert wird. Die Antwort dazu lautet: Für
alle Methoden wird Code generiert, der den Methodenaufruf an die einzige Methode invoke
der Schnittstelle InvocationHandler aus der Refl ection-Bibliothek delegiert:
package java.lang.reflect;
public interface InvocationHandler
{
public Object invoke(Object proxy, Method m, Object[] args)
throws Throwable;
}
Die übergebenen Parameter sind das dynamische Proxy-Objekt, von dem der Aufruf kommt
(also this aus Sicht des aufrufenden dynamischen Proxy-Objekts), die aufgerufene Methode
in Form eines Method-Objekts (Klasse Method aus der Refl ection-Bibliothek) sowie die
Parameter der Methode m in Form eines Object-Felds. Sie fragen sich nun vielleicht, auf
welches Objekt die Methode invoke angewendet wird. Die Antwort darauf lautet: Die dyna-
misch erzeugte Proxy-Klasse besitzt einen Konstruktor mit einem Parameter des Typs Invo-
cationHandler. Das heißt, dass man eine eigene Klasse programmieren muss, die die
Schnittstelle InvocationHandler implementiert. In dieser Klasse schreibt man durch Imple-
mentierung der Methode invoke den Code, der die Funktionalität des dynamischen Proxy
eigentlich ausmacht. Man erzeugt dann ein Objekt dieser Klasse und übergibt dieses Objekt
als Konstruktorargument beim Erzeugen eines Objekts der dynamisch erzeugten Proxy-
Klasse. An dieses als Konstruktorargument übergebene Objekt werden alle Methodenaufrufe
des dynamischen Proxy delegiert. In Bild 4.4 ist die Situation grafi sch dargestellt, wobei mit
I die Server-Schnittstelle bezeichnet wird, die auch vom dynamischen Proxy implementiert
wird. In dieser Abbildung wird davon ausgegangen, dass der Code der InvocationHandler
implementierenden Klasse auf den Server zugrei , vor den das Proxy-Objekt gesetzt wird.
Dies ist zwar nicht zwingend notwendig, ist aber für Proxies der Normalfall, wie in der Ein-
leitung zu diesem Kapitel dargestellt wurde.
Invocaon-
Handler
I
I
Invocaon
-Handler-
Impl.
Dynamic
Proxy
Client
Server
Bild 4.4
Strukturbild für einen mit Refl ection erzeugten DynamicProxy
