15.3    Die Klasse Class 

Angenommen, wir wollen einen Klassen-Browser schreiben. Dieser soll alle zum laufenden Programm gehörenden Klassen und darüber hinaus weitere Informationen anzeigen, wie etwa Variablenbelegung, deklarierte Methoden, Konstruktoren und Informationen über die Vererbungshierarchie. Dafür benötigen wir die Bibliotheksklasse Class. Exemplare der Klasse Class sind Objekte, die entweder eine Java-Klasse oder Java-Schnittstelle repräsentieren. (Dass auch Schnittstellen durch Class-Objekte repräsentiert werden, wird im Folgenden nicht mehr ausführlich erwähnt.)

In diesem Punkt unterscheidet sich Java von vielen herkömmlichen Programmiersprachen, da sich Eigenschaften von Klassen vom gerade laufenden Programm mithilfe der Class-Objekte abfragen lassen. Bei den Exemplaren von Class handelt es sich um eine eingeschränkte Form von Meta-Objekten[ 236 ](Echte Metaklassen wären Klassen, deren jeweils einziges Exemplar die normale Java-Klasse ist. Dann wären etwa die normalen Klassenvariablen in Wahrheit Objektvariablen in der Metaklasse. ) – die Beschreibung eines Java-Typs, die aber nur ausgewählte Informationen preisgibt. Neben normalen Klassen werden auch Schnittstellen durch ein Class-Objekt repräsentiert, und sogar Arrays und primitive Datentypen – statt Class wäre wohl der Klassenname Type passender gewesen.

 

15.3.1    An ein Class-Objekt kommen 

Zunächst müssen wir für eine bestimmte Klasse das zugehörige Class-Objekt in Erfahrung bringen. Class-Objekte selbst kann nur die JVM erzeugen. Wir können das nicht (die Objekte sind immutable, und der Konstruktor ist privat).[ 237 ](Und in der Javadoc heißt es: »Constructor. Only the Java Virtual Machine creates Class objects.« ) Um einen Verweis auf ein Class-Objekt zu bekommen, bieten sich folgende Lösungen an:

• Ist ein Exemplar der Klasse verfügbar, rufen wir die getClass()-Methode des Objekts auf und erhalten das Class-Exemplar der zugehörigen Klasse.

• Jeder Typ enthält eine statische Variable mit dem Namen .class vom Typ Class, die auf das zugehörige Class-Exemplar verweist.

• Auch auf primitiven Datentypen ist das Ende .class erlaubt. Das gleiche Class-Objekt liefert die statische Variable TYPE der Wrapper-Klassen. Damit ist int.class == Integer.TYPE.

• Die Klassenmethode Class.forName(String) kann eine Klasse erfragen, und wir erhalten das zugehörige Class-Exemplar als Ergebnis. Ist der Typ noch nicht geladen, sucht und bindet forName(String) die Klasse ein. Weil das Suchen schiefgehen kann, ist eine ClassNotFoundException möglich.

• Haben wir bereits ein Class-Objekt, sind aber nicht an ihm, sondern an seinen Vorfahren interessiert, so können wir einfach mit getSuperclass() ein Class-Objekt für die Oberklasse erhalten.

Das folgende Beispiel zeigt drei Möglichkeiten auf, um an ein Class-Objekt für java.util.Date heranzukommen:

Listing 15.2    src/main/java/com/tutego/insel/meta/GetClassObject.java, main()

Class<Date> c1 = java.util.Date.class;

System.out.println( c1 );        // class java.util.Date

Class<?> c2 = new java.util.Date().getClass();

 // oder Class<? extends Date> c2 = ...



System.out.println( c2 );        // class java.util.Date

try {

  Class<?> c3 = Class.forName( "java.util.Date" );

  System.out.println( c3 );      // class java.util.Date

}

catch ( ClassNotFoundException e ) { e.printStackTrace(); }

Die Variante mit forName(String) ist sinnvoll, wenn der Name der gewünschten Klasse bei der Übersetzung des Programms noch nicht feststand. Sonst ist die vorhergehende Technik eingängiger, und der Compiler kann prüfen, ob es den Typ gibt. Eine volle Qualifizierung ist nötig, Class.forName("Date") würde nur nach Date in dem Default-Paket suchen – die Rückgabe ist ja keine Sammlung.

class java.lang.Object

• final Class<? extends Object> getClass()
  
  Liefert zur Laufzeit das Class-Exemplar, das die Klasse des Objekts repräsentiert.

final class java.lang.Class<T>

implements Serializable, GenericDeclaration, Type, AnnotatedElement

• static Class<?> forName(String className) throws ClassNotFoundException
  
  Liefert das Class-Exemplar für die Klasse oder Schnittstelle mit dem angegebenen voll qualifizierten Namen. Falls sie bisher noch nicht vom Programm benötigt wurde, sucht und lädt der Klassenlader die Klasse. Die Methode liefert niemals null zurück. Falls die Klasse nicht geladen und eingebunden werden konnte, gibt es eine ClassNotFoundException. Eine alternative Methode forName(String name, boolean initialize, ClassLoader loader) ermöglicht auch das Laden mit einem gewünschten Klassenlader. Der Klassenname muss immer voll qualifiziert sein.

ClassNotFoundException und NoClassDefFoundError *

Eine ClassNotFoundException lösen die Methoden

• forName(…) aus Class und

• loadClass(String name [, boolean resolve]) aus ClassLoader bzw.

• findSystemClass(String name) aus ClassLoader

immer dann aus, wenn der Klassenlader die Klasse nach ihrem Klassennamen nicht finden kann. Auslöser ist also die Anwendung, die dynamisch Typen laden will, die dann aber nicht vorhanden sind.

Neben der Exception-Klasse gibt es ein NoClassDefFoundError – ein harter LinkageError, den die JVM immer dann auslöst, wenn sie eine im Bytecode referenzierte Klasse nicht laden kann. Nehmen wir zum Beispiel eine Anweisung wie new MeineKlasse(). Führt die JVM diese Anweisung aus, versucht sie, den Bytecode von MeineKlasse zu laden. Ist der Bytecode für MeineKlasse nach dem Compilieren entfernt worden, löst die JVM durch den nicht geglückten Ladeversuch den NoClassDefFoundError aus. Auch tritt der Fehler auf, wenn beim Laden des Bytecodes die Klasse MeineKlasse zwar gefunden wurde, aber MeineKlasse einen statischen Initialisierungsblock besitzt, der wiederum eine Klasse referenziert, für die keine Klassendatei vorhanden ist.

Während ClassNotFoundException häufiger vorkommt als NoClassDefFoundError, ist die Ausnahme im Allgemeinen ein Indiz dafür, dass ein Java-Archiv im Modulpfad fehlt.

Probleme nach Anwendung eines Obfuscators *

Dass der Compiler automatisch Bytecode gemäß diesem veränderten Quellcode erzeugt, führt nur dann zu unerwarteten Problemen, wenn wir einen Obfuscator über den Programmtext laufen lassen, der nachträglich den Bytecode modifiziert und damit die Bedeutung des Programms bzw. des Bytecodes verschleiert und dabei Typen umbenennt. Offensichtlich darf ein Obfuscator Typen, deren Class-Exemplare abgefragt werden, nicht umbenennen – oder der Obfuscator müsste die entsprechenden Zeichenketten ebenfalls korrekt ersetzen (aber natürlich nicht alle Zeichenketten, die zufällig mit Namen von Klassen übereinstimmen).

 

15.3.2    Eine Class ist ein Type 

In Java gibt es unterschiedliche Typen, wobei Klassen, Schnittstellen und Aufzählungstypen von der JVM als Class-Objekte repräsentiert werden. In der Reflection-API repräsentiert die Schnittstelle Type alle Typen. Das ist bisher die implementierende Klasse Class, und dazu kommen einige Unterschnittstellen:

• ParameterizedType (repräsentiert generische Typen wie List<T>)

• TypeVariable<D> (repräsentiert beispielsweise T extends Comparable<? super T>)

• WildcardType (repräsentiert etwa ? super T)

• GenericArrayType (repräsentiert so etwas wie T[])

Die einzige Methode von Type ist getTypeName(), und das ist sogar »nur« eine Default-Methode, die toString() aufruft.

Type ist die Rückgabe diverser Methoden in der Reflection-API, etwa von getGenericSuperclass() und getGenericInterfaces() der Klasse Class und von vielen weiteren Methoden, die die Javadoc unter »USE« aufzählt.