6.8 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.

Hier klicken, um das Bild zu Vergrößern

6.8.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() );

Klassen-Literale

Ein Klassen-Literal (eng. class literal) ist ein Ausdruck der Form Datentyp.class, wobei Datentyp entweder eine Klasse, eine Schnittstelle, ein Feld oder ein primitiver Typ ist. Der Ausdruck ist immer vom Typ Class. Beispiele sind Object.class oder int.class.

6.8.2 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 Argument aufgerufen werden. Ähnliches gilt für den Zeichenkettenoperator + mit einer Objektreferenz als Operand.

Listing 6.36   DiskoAusgabe.java

public class DiskoAusgabe
{
  int anzahlPersonen;
  int quadratmeter;

  public String toString()
  {
    return getClass().getName() +
           "[anzahlPersonen=" + anzahlPersonen +
           ",quadratmeter=" + quadratmeter + "]";
  }

  public static void main(String[] args)
  {
    DiskoAusgabe d = new DiskoAusgabe();
    d.anzahlPersonen = 1223; 
// DiskoAusgabe[anzahlPersonen=1223,quadratmeter=633]
    d.quadratmeter = 633;    
// :DiskoAusgabe[anzahlPersonen=1223,quadratmeter=633]:

    System.out.println( d );
    System.out.println( ":" + d + ":");
  }
}

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

6.8.3 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() 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 gleich einem anderen 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, so dass 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 gleich sich selbst, 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.

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);
}

Die equals()-Funktion stellt einige Anforderungen:

Heißt der Vergleich equals(null), so ist das Ergebnis immer false.

Kommt ein this rein, lässt sich eine Abkürzung nehmen und true zurückliefern.

Das Argument ist zwar vom Typ Object, aber dennoch vergleichen wir immer konkrete Typen. Eine equals()-Funktion einer Klasse X wird sich daher nur mit Objekten vom Typ X vergleichen lassen.

Die ersten beiden Punkt sind leicht erfüllt. Nehmen wir dazu ein Beispiel einer Klasse DiskoEquals.

Listing 6.37   DiskoEquals.java, erster Versuch

public class DiskoEquals
{
  int anzahlPersonen;
  int quadratmeter;

  public boolean equals( Object o )
  {
    if ( o == null )
      return false;

    if ( o == this )
      return true;

    DiskoEquals that = (DiskoEquals) o;

    return    this.anzahlPersonen == that.anzahlPersonen
           && this.quadratmeter   == that.quadratmeter;
  }
}

Diese Lösung erscheint offensichtlich, führt aber spätestens bei einem nicht-DiskoEquals-Objekt zu einer ClassCastException. Das ist schnell behoben:

if ( ! o instanceof DiskoEquals )
  return false;

Jetzt sehen wir uns auf der sicheren Seite, aber das Ziel ist noch nicht ganz erreicht. Zwar funktioniert die aufgeführte Implementierung bei finalen Klassen schön, aber bei Unterklassen ist die Symmetrie gebrochen. Warum? Ganz einfach: instanceof testet Typen in der Hierarchie, liefert also auch dann true, wenn das an equals() übergebene Argument eine Unterklasse von DiskoEquals ist. Diese Unterklasse wird wie die Oberklasse die gleichen Attribute haben, so dass – aus Sicht von DiskoEquals – alles in Ordnung ist. Nehmen wir im Moment einmal die Variablen disko und superDisko an, die die Typen DiskoEquals und SuperDiskoEquals – die Unterklasse von DiskoEquals – besitzen. Sind beide Objekte gleich, so ergibt disko.equals(superDisko) das Ergebnis true. Drehen wir den Spieß nun um, und fragen, was superDisko.equals(disko) ergibt. Zwar haben wir SuperDiskoEquals nicht implementiert, aber nehmen wir an, dass dort eine equals()-Funktion steckt, die nach dem gleichen instanceof-Schema implementiert wurde wie DiskoEquals. Dann wird dort bei einem Test ausgeführt: disko instanceof superDisko und das ist false. Damit wird aber die Fallunterscheidung mit return false beendet. Fassen wir zusammen:

disko.equals( superDisko ) == true
superDisko.equals( disko ) == false

Das darf nicht sein und zur Lösung dürfen wir nicht instanceof verwenden, sondern müssen fragen, ob der Typ exakt ist. Das geht mit getClass(). Korrekt ist daher folgendes:

Listing 6.38   DiskoEquals.java, Korrektur

public class DiskoEquals
{
  int anzahlPersonen;
  int quadratmeter;

  public boolean equals( Object o )
  {
    if ( o == null )
      return false;

    if ( o == this )
      return true;

      if ( ! o.getClass().equals(getClass()) )  
        return false;  

    DiskoEquals that = (DiskoEquals) o;

    return    this.anzahlPersonen == that.anzahlPersonen
      && this.quadratmeter   == that.quadratmeter;
}
}

Es ist günstig, bei erweiterten Klassen ein neues equals() anzugeben, so dass 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.8.4 Klonen eines Objekts mit clone() 

Zum Replizieren eines Objekts lässt sich eine vordefinierte Methode einsetzen: clone(). Der Aufruf soll eine Kopie des Objekts liefern.

java.awt.Point p = new java.awt.Point(12, 23);
java.awt.Point q = (java.awt.Point) p.clone();
System.out.println( q );             // java.awt.Point[x=12,y=23]

Viele der Standard-Klassen unterstützen ein clone(), so dass ein neues Exemplar mit dem gleichen Zustand zurückgegeben wird. Für uns als Programmierer stellt sich die Frage, wie ein clone() unserer Klassen mit geringem Aufwand umgesetzt wird. Zwei Möglichkeiten kommen in betracht:

Lösung zwei verkürzt die Entwicklungszeit und ist auch spannender. Denn um das System zum Klonen zu bewegen, müssen zwei Dinge getan werden:

Die Funktion public Object clone() muss überschrieben werden. Weiterhin muss die Funktion clone() der Oberklasse mit super.clone() aufgerufen werden. Dies wird oft die Funktion clone() aus Object sein. Sie selbst ist protected, aber das ist der Trick: Nur Unterklassen können clone() aufrufen, keiner sonst.

Es muss die Markierungsschnittstelle Cloneable implementiert werden. Falls von außen ein clone() auf einem Objekt aufgerufen wird, dessen Klasse nicht Cloneable implementiert, ist das Ergebnis eine CloneNotSupportedException.

Nach dem Aufrufen der Oberklassenfunktion mit super.clone() erzeugt das Laufzeitsystem ein 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. Die Funktion kann einen OutOfMemoryError liefert, wenn es keinen freien Speicher mehr gibt.

public class Bedienung implements Cloneable
{
  String name;
  int alter;

  public Object clone()
  {
    try
    {
      return super.clone();
    }
    catch ( CloneNotSupportedException e ) {
      // this shouldn’t happen, since we are Cloneable
      throw new InternalError();
    }
  }
}

Hier klicken, um das Bild zu Vergrößern

Testen wir die Klasse etwa so:

Bedienung susi = new Bedienung();
susi.name = "Susi";
Bedienung dolly = (Bedienung) susi.clone();
System.out.println( dolly.name );   // Susi

clone() und equals()

Die Methode clone() und die Methode equals() hängen wie auch equals() und hashCode() zusammen. Wenn die clone()-Methode überschrieben wird, sollte auch equals() angepasst werden, denn ohne ein überschriebenes equals() bleibt in Object stehen:

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

Das heißt aber, dass ein geklones Objekt – welches ja im Allgemeinen ein neues Objekt ist – durch seine neue Objektidentität nicht mehr equals() zu seinem Erzeuger ist. Formal: o.clone().equals(o) == false. Diese Semantik dürfte nicht erwünscht sein.

Flach oder tief?

clone() erzeugt standardmäßig nur flache Kopien. Bei untergeordneten Objekten werden nur die Referenzen kopiert und Originalobjekt sowie Kopie verweisen anschließend auf dieselben untergeordneten Objekte (verwenden diese gemeinsam). Wenn zum Beispiel die Bedienung ein Attribut für einen Arbeitgeber besitzt und eine Kopie der Bedienung erzeugt wird, so wird der Klon auf den gleichen Arbeitgeber zeigen. Bei einem Arbeitgeber mag das noch stimmig sein, aber bei Datenstrukturen sind mitunter tiefe Kopien gewünscht.

Kovariante Rückgabewerte

Bisher sieht die Java-Sprachdefinition nicht vor, dass es mehrere Methoden in einer Klasse geben kann, die sich nur in ihren Rückgabetypen unterscheiden. Das wären kovariante Rückgabewerte. Ebenfalls ist es nicht möglich, in einer Unterklasse eine Methode zu überschreiben, die einen anderen Rückgabetyp besitzt. Die Methode würde nicht überschrieben, und es gibt einen Compilerfehler, da ererbte und neue Methode gegen die Regel verstoßen, dass zwei Methoden sich nie nur im Rückgabetyp unterscheiden dürfen.

Im Design von großen Programmen wäre es jedoch günstig, wenn ein nichtprimitiver Rückgabetyp einer überschriebenen Funktion ebenfalls vom Typ dieser Unterklasse ist. Auf diese Weise ließen sich korrekt angepasste, überschriebene Methoden implementieren, und Entwickler könnten sich die expliziten Typanpassungen ersparen.

class X        // automatisch extends Object
{
  public X clone()
  {
    return (X)super.clone();
  }
}

Der Aufrufer der Methode clone() von X muss selbstständig eine Typumwandlung auf X vornehmen.

Das Komische in diesem Zusammenhang ist, dass es schon veränderte Zugriffsrechte gibt. Eine Unterklasse kann die Sichtbarkeit erweitern. Auch bei Ausnahmen kann eine Unterklasse speziellere Ausnahmen beziehungsweise ganz andere als die Methode der Oberklasse erzeugen.

Die aktuelle Sprachdefinition von C++ unterstützt kovariante Rückgabewerte. Im Zuge der kommenden Version 5 werden auch kovariante Rückgabewerte in die Sprache Einzug erhalten. Auch einige Java-Erweiterungen, unter ihnen der freie GJ-Compiler, erlauben kovariante Rückgabewerte ohne Änderung der JVM durch Einfügen von Typanpassungen.

6.8.5 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 implementieren eine solche Datenstruktur.

Listing 6.39   DiskoHashing.java

public class DiskoHashing
{
  int anzahlPersonen;
  int quadratmeter;

  /**
   * Liefert den Hashcode für das aktuelle <code>DiskoHashing</code>-Objekt.
   *
   * @return Hashcode.
   */
  public int hashCode()
  {
    return anzahlPersonen ^ ( quadratmeter >> 16 );
  }

  public static void main( String[] args )
  {
    DiskoHashing d = new DiskoHashing();
    d.anzahlPersonen = 1223;
    d.quadratmeter = 633;

    System.out.println( d.hashCode() );   // 1726
  }
}

Equals, die Null und Hashen

Die beiden Methoden hashCode() und equals() hängen zusammen, so dass 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.

6.8.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.8.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.