43.1 Einleitung

• 43.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 werden in Kapitel 44 behandelt.