9.7 this in Unterklassen *
Wenn wir ein qualifiziertes this verwenden, dann bezeichnet C.this die äußere Klasse, also das umschließende Exemplar. Das haben wir schon in Abschnitt 9.3.2, »Die this-Referenz«, gelernt. Gilt jedoch die Beziehung C1.C2.….Ci.….Cn., dann haben wir mit Ci.this ein Problem, wenn Ci eine Oberklasse von Cn ist. Es geht also um den Fall, dass eine textuell umgebende Klasse zugleich Oberklasse ist. Das eigentliche Problem besteht darin, dass hier zweidimensionale Namensräume hierarchisch kombiniert werden müssen. Die eine Dimension sind die Variablen und Methoden aus den lexikalisch umgebenden Klassen, die andere Dimension sind die ererbten Eigenschaften aus der Oberklasse. Hier sind beliebige Überlappungen und Mehrdeutigkeiten denkbar. Durch diese ungenaue Beziehung zwischen inneren Klassen und Vererbung kam es unter JDK 1.1 und 1.2 zu unterschiedlichen Ergebnissen. Aber das ist ja schon Steinzeit ...
Im nächsten Beispiel soll von der Klasse Shoe die innere Klasse LeatherBoot den Shoe erweitern und die Methode out() überschreiben:
public class Shoe {
void out() {
System.out.println( "Ich bin der Schuh des Manitu." );
}
class LeatherBoot extends Shoe {
void what() {
Shoe.this.out();
}
@Override
void out() {
System.out.println( "Ich bin ein Shoe.LeatherBoot." );
}
}
public static void main( String[] args ) {
(new Shoe()).new LeatherBoot().what();
}
}
Legen wir in der statischen main(…)-Methode ein Objekt der Klasse LeatherBoot an, dann landen wir bei what() in der Klasse LeatherBoot, was Shoe.this.out() ausführt. Interessant ist aber, dass hier kein dynamisch gebundener Aufruf an out() vom LeatherBoot-Objekt erfolgt, sondern die Ausgabe von Shoe stammt:
Ich bin der Schuh des Manitu.
Die überschriebene Ausgabe von LeatherBoot liefert die ähnlich aussehende Anweisung ((Shoe)this).out(). Vor Version 1.2 kam als Ergebnis immer diese Zeichenkette heraus, aber das ist Geschichte und nur eine historische Randnotiz.
9.7.1 Geschachtelte Klassen greifen auf private Eigenschaften zu
Die äußere umschließende Klasse kann auf private Eigenschaften der geschachtelten Klasse zugreifen. Das folgende Beispiel soll das illustrieren:
public class NotSoPrivate {
private static class Family { private String dad, mom; }
public static void main( String[] args ) {
class Node { private Node next; }
Node n = new Node();
n.next = new Node();
Family ullenboom = new Family();
ullenboom.dad = "Heinz";
ullenboom.mom = "Eva";
}
}
Eine Klasse Outsider, die in der gleichen Compilationseinheit (also Datei) definiert wird, kann schon nicht mehr auf NotSoPrivate.Family zugreifen, und natürlich hat auch keine Klasse einer anderen Compilationseinheit Zugriff.
Zugriffsrechte *
Eine geschachtelte Klasse kann auf alle Attribute der äußeren Klasse zugreifen. Da eine geschachtelte Klasse in eine ganz normale Klassendatei übersetzt wird, stellt sich allerdings die Frage, wie sie das genau macht. Auf öffentliche Variablen kann jede andere Klasse ohne Tricks zugreifen, so auch die geschachtelte. Und da eine geschachtelte Klasse als normale Klassendatei im gleichen Paket sitzt, kann sie ebenfalls ohne Verrenkungen auf paketsichtbare und protected-Eigenschaften der äußeren Klasse zugreifen. Eine geschachtelte Klasse kann jedoch auch auf private Eigenschaften zurückgreifen – eine Designentscheidung, die sehr umstritten ist und lange kontrovers diskutiert wurde. Doch wie ist das zu schaffen, ohne gleich die Zugriffsrechte des Attributs zu ändern? Der Trick ist, dass der Compiler eine synthetische statische Methode in der äußeren Klasse einführt:
class House {
private String owner;
static String access$0( House house ) {
return house.owner;
}
}
Die statische Methode access$0(…) ist der Helfershelfer, der für ein gegebenes House das private Attribut nach außen gibt. Da die geschachtelte Klasse einen Verweis auf die äußere Klasse pflegt, gibt sie diesen beim gewünschten Zugriff mit, und die access$0(…)-Methode erledigt den Rest.
Für jedes von der geschachtelten Klasse genutzte private Attribut erzeugt der Compiler eine solche Methode. Wenn wir eine weitere private Variable int size hinzunähmen, würde der Compiler ein int access$1(House) generieren.
[»] Hinweis
Problematisch ist das bei Klassen, die in ein Paket hineingeschmuggelt werden. Nehmen wir an, House liegt im Paket p1.p2. Dann kann ein Angreifer seine Klassen auch in ein Paket legen, das p1.p2 heißt. Da die access$XXX(…)-Methoden paketsichtbar sind, können hineingeschmuggelte Klassen die paketsichtbaren access$XXX(…)-Methoden aufrufen. Es reicht ein Exemplar der äußeren Klasse, um über einen access$XXX(…)-Aufruf auf die privaten Variablen zuzugreifen, die eine innere Klasse nutzt. Glücklicherweise lässt sich gegen eingeschleuste Klassen in Java-Archiven leicht etwas unternehmen – sie müssen nur mit dem Jar-Werkzeug abgeschlossen werden, was bei Java Sealing heißt.