Das Reflection-API informiert zur Laufzeit über Klassen, ihre Methoden und Felder. So bildet es die Basis für die Komponentensysteme Beans und J2EE. Der Coffee-Shop zeigt, wie sich mit Reflection dynamisch Klassen laden und ausführen lassen.
Wer bin ich? Das fragt sich nicht nur mancher Programmierer nach durchhackter Nacht, auch die Software selbst gerät bisweilen in eine Identitätskrise. Kompiliertem Code fällt es meist schwer, die ursprünglichen High-Level-Informationen zu rekonstruieren. Objektorientierte Sprachen besitzen dafür oft ein nützliches Gegenmittel: Introspection, Metaprogrammierung und Reflection sind Mechanismen, die es Code ermöglichen, Kenntnis über die zugrunde liegenden Klassen zu erhalten. Das ermöglicht das Laden dynamischer Codeteile, die Entwicklung komponentenbasierter Systeme und klügerer Tools für objektorientiertes Software-Engineering.
So genannte Case-Tools (Computer-aided Software Engineering) konnten sich bisher nicht auf breiter Basis durchsetzen. Eine der Ursachen ist, dass zwar der Weg vom Case-Tool zum Code funktioniert, der Rückweg aber oft nicht. Und wer will schon den eigenen Code innerhalb eines Case-Tools pflegen, wo es doch hervorragende Editoren gibt? Und wenn der Code nur in kompilierter Form vorliegt, ist in den meisten Sprachen sowieso Schluss.
In Teilbereichen erweisen sich solche Tools aber durchaus als hilfreich, beispielsweise bei der Verwaltung von Klassen in der objektorientierten Programmierung. Java unterstützt das seit Version 1.1 durch die neuen Klassen des Reflection-API. Der Name geht darauf zurück, dass das API es einem laufenden Programm erlaubt, sich selbst zu betrachten, genauer: seine Klassen, Felder und Methoden. Denn Javas Sprachkern bietet hier anders als andere Sprachen keine wirkliche Unterstützung (es gibt nur den »instanceof«-Operator).
Die folgenden Abschnitte erläutern das Prinzip und wichtige Klassen des Reflection-API, zeigen Einsatzgebiete und demonstrieren an einem Beispiel, wie man das API nutzt, auch wenn es nicht um Entwicklungstools oder Komponentensysteme geht.
Die Datei beginnt mit der hexadezimalen Magic-Nummer »cafebabe«, danach folgen Informationen zur Klasse (Abbildung 1). Schon vor dem JDK 1.1 konnte man diese Information auslesen und sinnvoll nutzen, was allerdings etwas mehr eigene Low-Level-Programmierung erforderte (siehe[2]).
Abbildung 1: Der Hex-Editor zeigt den Anfang des kompilierten Java-File, also der Bytecode-Datei zur Klasse »GuiSearcher«.
Mit dem Reflection-API ist es nicht mehr notwendig, die Datei selbst zu parsen. Das übernehmen die Klasse »java.lang.Class« sowie die Klassen im Package »java.lang.reflect« (Constructor, Field, Method ...). Sie parsen selbst die Class-Datei und liefern alle Informationen zurück, die darin enthalten sind.
Die Aufteilung des Reflection-API auf mehr als ein Package ist historisch bedingt und kommt auch an anderen Stellen vor, zum Beispiel bei den Font-Klassen, vergleiche[1]. Die Klasse »Class« existiert schon seit der Version 1.0 des JDK, wurde aber mit 1.1 deutlich erweitert. Die neuen Klassen sind alle im Package »java.lang.reflect« zu finden.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
