6.9 Die oberste aller Klassen: Object 

Wie schon an anderer Stelle betont, ist Object – definiert in der Klassendatei java.lang.Object – die oberste aller Klassen. Somit spielt diese Klasse eine ganz besondere Rolle, da alle anderen Klassen automatisch Unterklassen sind und die Methoden erben beziehungsweise überschreiben.

6.9.1 Klassenobjekte 

Zwar ist jedes Objekt ein Exemplar einer Klasse – doch was ist eine Klasse? In Sprachen wie C++ existieren keine Klassen zur Laufzeit und der Compiler übersetzt die Klassenstruktur in ein Programm. Im absoluten Gegensatz dazu steht Smalltalk: Diese Laufzeitumgebung verwaltet alle Klassen als Objekte. Die speziellen Klassenobjekte bilden dann den Bauplan für neue Exemplare.

Die Klasse Object bietet eine spezielle Methode getClass() an, die eine Referenz auf das Klassenobjekt vom Typ java.lang.Class zurückgibt, die das Objekt konstruiert hat. Der Vorteil liegt klar auf der Hand: Wenn Klassen als Objekte vorliegen, dann können sie auch über das Netz geladen und ausgeführt werden. Ein Nachteil ist die verminderte Geschwindigkeit. Doch das wird gerne in Kauf genommen.

System.out.println( "Klaviklack".getClass().getName() );

6.9.2 Hashcodes 

Die Methode hashCode() soll zu jedem Objekt eine möglichst eindeutige Integerzahl (sowohl positiv als auch negativ) liefern, die das Objekt identifiziert. Inhaltlich gleiche Objekte (gemäß der Methode equals()) müssen denselben Wert bekommen. Eine spezielle Funktion berechnet diesen Wert, der Hashcode oder Hash-Wert genannt wird. Die Funktionen, die solche Werte berechnen, nennen sich Hash-Funktionen.

Hashcodes werden verwendet, um Elemente in Hash-Tabellen zu speichern. Diese sind Datenstrukturen, die einen effizienten Zugriff auf ihre Elemente erlauben. Die Klassen java.util.HashMap oder java.util.Hashtable bieten eine solche Datenstruktur an.

6.9.3 Objektidentifikation mit toString() 

Jedes Objekt sollte sich durch die Methode toString() mit einer Zeichenkette identifizieren und den Inhalt der interessanten Attribute als Zeichenkette liefern.

Neue Klassen sollten diese Methode überschreiben. Wenn das nicht der Fall ist, gelangt das Programm zur Standardimplementierung in Object:

public String toString()
{
    return getClass().getName()+"@"+
             Integer.toHexString(hashCode());
}

Dann wird lediglich der Klassenname und der nichts sagende Hash-Wert hexadezimal ausgeben.

Das Angenehme ist, dass toString() automatisch aufgerufen wird, wenn die Methoden print() oder println() mit einer Objektreferenz als Parameter aufgerufen werden. Ähnliches gilt für den Zeichenkettenoperator + mit einer Objektreferenz als Operand:

MeinObjekt meinObi = new MeinObjekt();
System.out.println( meinObi );
String s = "Alles bei " + meinObi;

Bei einer eigenen Implementierung müssen wir darauf achten, dass die Sichtbarkeit public ist, da toString() in der Oberklasse public ist und wir die Sichtbarkeit nicht einschränken können.

6.9.4 Objektgleichheit mit equals() und Identität 

Ob zwei Referenzen auf das gleiche Objekt zeigen, lässt sich durch den Vergleichsoperator == feststellen. Damit wird aber lediglich die Identität, nicht jedoch automatisch die inhaltliche Gleichheit getestet. So wird der Vergleich

if ( meinName == "Ulli" )

gewiss einen falschen, unbeabsichtigten Effekt haben, obwohl er syntaktisch korrekt ist. An dieser Stelle sollte der inhaltliche Vergleich stattfinden: Stimmen alle Zeichen der Zeichenkette überein?

Mit der Methode equals()6 aus Object lassen sich Objekte auf Gleichheit prüfen. Unterklassen überschreiben diese Methode, um einen inhaltlichen Vergleich vorzunehmen. Die Methode ist in jeder Klasse auch gut aufgehoben, denn nur ein Objekt weiß, wann es mit einem anderen gleich ist. So besitzt das String-Objekt eine Implementierung, die jedes Zeichen vergleicht:

String meinName = "Ulli";

if ( meinName.equals( "Ulli" ) )
  // gefunden

Leider implementiert nicht jede Klasse eine eigene equals()-Methode, sodass die Laufzeitumgebung unbeabsichtigt bei Object und seinem Referenzenvergleich landet. Diese Fehleinschätzung kommt leider bei Exemplaren der Klasse StringBuffer vor, die kein eigenes equals() implementiert. Wir haben die Diskussion darüber schon geführt.

Ein weiterer Aspekt von equals()¹  ist folgender: Das Ergebnis muss über die gesamte Lebensdauer eines Objekts immer gleich bleiben. Ein kleines Problem steckt dabei in equals() der Klasse URL, die vergleicht, ob zwei URL-Adressen auf die gleiche Ressource zeigen. Der Vergleich vertraut auf die IP-Adresse des Rechners, was jedoch sehr problematisch ist. Gerade die Abstraktion von veränderbaren IP-Adressen mit ihren dynamischen Auflösungen machen URLs attraktiv. Eine IP-Adresse eines Rechners kann sich ändern, auch wenn sich die URL nicht ändert. Das heißt, ändert sich die IP-Adresse des Rechners, ist auf einmal ein URL-Objekt nicht mehr mit sich selbst gleich, obwohl die URL unverändert bleibt. Den Fehler sollten wir bei unseren Programmen nicht machen. Wenn der Test auf Gleichheit nicht möglich ist, müssen wir einen Test definieren, der möglich ist (etwa Vergleich der URL-Daten, wie Rechnername und Datei), oder auf den Test verzichten und beim Vergleich der Referenzen bleiben.

Equals, die Null und Hashen

Heißt der Vergleich equals(null), so ist das Ergebnis immer false. Die beiden Methoden hashCode() und equals() hängen zusammen, sodass in der Regel bei der Implementierung einer Funktion auch eine Implementierung der anderen notwendig wird. Denn es gilt, dass bei Gleichheit natürlich auch die Hash-Werte übereinstimmen müssen. Formal gesehen heißt das:

x.equals(y)      ==>     x.hashCode() == y.hashCode()

So berechnet sich der Hashcode bei Point-Objekten aus den Koordinaten. Zwei Punkt-Objekte, die inhaltlich gleich sind, haben die gleichen Koordinaten und damit auch den gleichen Hashcode.

Ein eigenes equals()

Bei selbstdefinierten Methoden ist Vorsicht geboten, denn wir müssen genau auf die Signatur achten. Die Methode muss ein Object akzeptieren und boolean zurückgeben. Wird diese Signatur falsch verwendet, so kommt es an Stelle einer Überschreibung der Funktion zu einer Überladung. Dies hat ungeahnte Folgen, denn dann wird einfach die Standardimplementierung aufgerufen. Diese kann über die Gleichheit von Objekten nichts wissen und testet lediglich die Referenzen.

public boolean equals( Object obj )
{
    return (this == obj);
}

Das Beispiel ist allgemein gehalten und zeigt, was für fast alle equals()-Methoden gilt. Wir wollen zudem unterscheiden, ob X eine direkte Unterklasse von Object ist oder Unterklasse einer weiteren Klasse O ist.

class X // extends O
{
  public boolean equals( Object o )
  {
  if ( o == null )
    return false;
  if ( o == this )
    return true;

  // Fall 1:
  // X ist direkte Unterklasse von Object
  if ( getClass() != o.getClass() )
    return false;
  // testet Gleichheit der Klassen einmal direkt unterhalb der
  // Klasse Object.

  // Fall 2:
  // X ist Unterklasse von O
  if ( !super.equals(o) )
    return false;
  // Attribute der Oberklasse (und Klassenzugehörigkeit)
  // verglichen.

  return equals( (X)o );
}
public boolean equals( X o )    // Sichtbarkeit nach Wunsch.
{
  // Vergleich, ob alle Attribute vom eigenen
  // Objekt, mit denen von o identisch sind.
  // Dann return true, sonst return false.

}

Es ist günstig bei erweiterten Klassen ein neues equals() anzugeben, sodass auch die neuen Attribute in den Test einbezogen werden. Bei hashCode()-Methoden müssen wir eine ähnliche Strategie anwenden, was wir hier nicht zeigen wollen.

6.9.5 Klonen eines Objekts mit clone() 

Ein Objekt kann sich selbst klonen. Nach dem Aufrufen der clone()-Methode erzeugt das Laufzeitsystem eine neues Exemplar der Klasse und kopiert elementweise die Daten des aktuellen Objekts in das neue. Jede Klasse bestimmt jedoch eigenständig, welche Attribute kopiert werden. Die Methode gibt eine Referenz auf das neue Objekt zurück. Zwei Fehler sind denkbar: Es gibt keinen freien Speicher mehr (OutOfMemoryError) oder das Objekt verbietet das Klonen (CloneNotSupportedException).

clone() erzeugt flache Kopien, das heißt, bei untergeordneten Objekten werden nur die Referenzen kopiert und Originalobjekt sowie Kopie verweisen anschließend auf dieselben untergeordneten Objekte (verwenden diese gemeinsam).

6.9.6 Aufräumen mit finalize() 

Eine spezielle Methode finalize() wird immer dann aufgerufen, wenn der GC ein Objekt entfernen möchte. Objekte sollten diese Funktion überschreiben, wenn sie beispielsweise noch Dateien schließen müssen. Achtung! Wenn noch genügend Speicherplatz vorhanden ist, wird womöglich der GC nie aufgerufen.

Überschreiben wir in einer Unterklasse diese Methode, dann müssen wir auch gewährleisten, dass finalize() der Oberklasse aufgerufen wird. Das erreichen wir mit der Referenz super. (Es wäre gut, wenn der Compiler das automatisch machen würde …)

class MehrAlsFontKann extends Font
{
  MehrAlsFontKann ()  // Font hat keinen Standard-Konstruktor
  {
    super( null, PLAIN, 10 );
  }

  protected void finalize() throws Throwable
  {
    /*
       MehrAlsFontKann Dinge freigeben
       ...
     */
     super.finalize();
  }
}

6.9.7 Synchronisation 

Threads können miteinander kommunizieren und dabei Daten teilen. Sie können außerdem auf das Eintreten bestimmter Bedingungen warten, zum Beispiel auf neue Eingabedaten. Die Klasse Object definiert insgesamt fünf Versionen der Methoden wait(), notify() und notifyAll() zur Beendigungssynchronisation von Threads. Ein Sonderkapitel geht näher auf die Programmierung von Threads ein.

¹   Die Mathematiker werden sich freuen, denn die Methode equals bildet eine Äquivalenzrelation. Sie ist, wenn wir die null-Referenz außen vor lassen, reflexiv, symmetrisch und transitiv.