45.1 Einleitung

• 45.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, musste der Code der Klasse zur Compile-Zeit 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 dass bereits zur Compile-Zeit ihr Name bekannt sein musste. Weiterhin sollten statische oder instanzbasierte Methoden aufgerufen und auf Membervariablen auch dann zugegriffen werden können, wenn ihr Name erst zur Laufzeit des Programms 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-API ansehen und ein paar nützliche Anwendungen vorstellen. Die als Introspection bezeichneten Erweiterungen für die Beans-Behandlung werden in Kapitel 46 behandelt.