31.1 Einleitung
Bei der Entwicklung des JDK 1.1 sahen sich die Entwickler mit einer
Schwäche von Java konfrontiert, die die Entwicklung bestimmter
Typen von Tools und Bibliotheken unmöglich machte: der statischen
Struktur von Klassen und Objekten. Um ein Objekt anzulegen, eine seiner
Methoden aufzurufen oder auf eine seiner Membervariablen zuzugreifen,
mußte der Code der Klasse zur Compilezeit bekannt sein.
Während dies für die meisten gewöhnlichen Anwendungen
kein Problem darstellt, ist es für die Entwicklung generischer
Werkzeuge und hochkonfigurierbarer Anwendungen, die durch PlugIns
erweiterbar sind, unzureichend. Insbesondere die Entwicklung der Beans-
und Serialisierungs-APIs war mit den in der Version 1.0 verfügbaren
Spracheigenschaften nicht möglich.
Benötigt wurde vielmehr die Möglichkeit, Klassen zu laden
und zu instanzieren (auch mit parametrisierten Konstruktoren), ohne
daß bereits zur Compilezeit ihr Name bekannt sein mußte.
Weiterhin sollten statische oder instanzbasierte Methoden aufgerufen
und auf Membervariablen auch dann zugegriffen werden können,
wenn ihr Name erst zur Laufzeit des Programmes bekannt ist.
Gesucht wurde also ein Mechanismus, der diese normalerweise vom Compiler
angeforderten Fähigkeiten des Laufzeitsystems auch "normalen"
Anwendungen zur Verfügung stellte. Mit dem Reflection-API des
JDK 1.1 wurde eine Library-Schnittstelle geschaffen, die alle erwähnten
Fähigkeiten (und noch einige mehr) implementiert und beliebigen
Anwendungen als integralen Bestandteil der Java-Klassenbibliothek
zur Verfügung stellt. Erweiterungen am Sprachkern waren dazu
nicht nötig.
Wir wollen uns in diesem Kapitel die wichtigsten Eigenschaften des
Reflection-APIs ansehen und ein paar nützliche Anwendungen vorstellen.
Die als Introspection bezeichneten Erweiterungen
für die Beans-Behandlung und den Zugriff auf Arrays via Reflection
wollen wir bei unseren Betrachtungen ausklammern.