Da anonyme Klassen keinen Namen haben, muss für Konstruktoren ein anderer Weg gefunden werden. Hier helfen Exemplarinitialisierungsblöcke, also Blöcke in geschweiften Klammern.
Exemplarinitialisierer gibt es ja eigentlich gar nicht im Bytecode, sondern der Compiler setzt den Programmcode automatisch in jeden Konstruktor. Obwohl anonyme Klassen keinen direkten Konstruktor haben können, gelangt doch über den Exemplarinitialisierer Programmcode in den Konstruktor der Bytecode-Datei.
Dazu ein Beispiel: Die anonyme Klasse ist eine Unterklasse von Point und initialisiert im Konstruktor einen Punkt mit Zufallskoordinaten. Aus diesem speziellen Punkt-Objekt lesen wir dann die Koordinaten wieder aus:
java.awt.Point p = new java.awt.Point() {
{
x = (int)(Math.random() * 1000); y = (int)(Math.random() * 1000);
}
};
System.out.println( p.getLocation() ); // java.awt.Point[…
System.out.println( new java.awt.Point( -1, 0 ) {{
y = (int)(Math.random() * 1000);
}}.getLocation() ); // java.awt.Point[x=-1,y=…]
Sprachlichkeit
Wegen der beiden geschweiften Klammen heißt diese Variante auch Doppelklammer-Initialisierung (engl. Double Brace Initialization).
Die Doppelklammer-Initialisierung ist kompakt, wenn etwas Datenstrukturen oder hierarchische Objekte initialisiert werden sollen.
Beispiel *
Im Folgenden Beispiel erwartet appendText(…) ein Objekt vom Typ HashMap, was durch den Trick direkt initialisiert wird:
String s = new DateTimeFormatterBuilder()
.appendText( ChronoField.AMPM_OF_DAY,
new HashMap<Long, String>() {{ put(0L, „früh“);put(1L,“spät“ ); }} )
.toFormatter().format( LocalTime.now() );
System.out.println( s );
Im nächsten Beispiel bauen wir eine geschachtelte Map, das ist ein Assoziativspeicher, der wieder einen anderen Assoziativspeicher enthält:
Map<String,Object> map = new HashMap<String,Object>() {{
put( „name“, „Chris“ );
put( „address“, new HashMap<String,Object>() {{
put( „street“, „Feenallee 1“ );
put( „city“, „Elefenberg“ );
}} );
}};
Warnung
Die Doppelklammerinitialisierung ist nicht ganz „billig“, da eine Unterklasse aufgebaut wird, also neuer Bytecode generiert wird. Zudem hält die innere Klasse eine Referenz auf die äußere Klasse fest. Des Weiteren kann es Probleme mit equals(…) geben, da wir mit der Doppelklammerinitialisierung eine Unterklasse schaffen, die vielleicht mit equals(…) nicht mehr gültig vergleichen werden kann, denn die Class-Objekte sind jetzt nicht mehr identisch. Das spricht in der Summe eher gegen diese Konstruktion.
Codeblöcke wären toll!