Galileo Computing < openbook >
Galileo Computing - Programming the Net
Galileo Computing - Programming the Net


Java ist auch eine Insel (2. Aufl.) von Christian Ullenboom
Programmieren für die Java 2-Plattform in der Version 1.4
Java ist auch eine Insel (2. Auflage)
gp Kapitel 6 Eigene Klassen schreiben
  gp 6.1 Eigene Klassen definieren
  gp 6.2 Assoziationen zwischen Objekten
  gp 6.3 Privatsphäre und Sichtbarkeit
    gp 6.3.1 Wieso nicht freie Methoden und Variablen für alle?
    gp 6.3.2 Privat ist nicht ganz privat. Es kommt darauf an, wer’s sieht
    gp 6.3.3 Zugriffsmethoden für Attribute definieren
    gp 6.3.4 Zusammenfassung zur Sichtbarkeit
  gp 6.4 Statische Methoden und Variablen
    gp 6.4.1 Warum statische Eigenschaften sinnvoll sind
    gp 6.4.2 Statische Eigenschaften mit static
    gp 6.4.3 Statische Eigenschaften als Objekteigenschaften nutzen
    gp 6.4.4 Statische Eigenschaften und Objekteigenschaften
    gp 6.4.5 Statische Variablen zum Datenaustausch
    gp 6.4.6 Warum die Groß- und Kleinschreibung wichtig ist
    gp 6.4.7 Konstanten mit dem Schlüsselwort final bei Variablen
    gp 6.4.8 Typsicherere Konstanten
    gp 6.4.9 Statische Blöcke
  gp 6.5 Objekte anlegen und zerstören
    gp 6.5.1 Konstruktoren schreiben
    gp 6.5.2 Einen anderen Konstruktor der gleichen Klasse aufrufen
    gp 6.5.3 Initialisierung der Objekt- und Klassenvariablen
    gp 6.5.4 Finale Werte im Konstruktor setzen
    gp 6.5.5 Exemplarinitialisierer (Instanzinitialisierer)
    gp 6.5.6 Zerstörung eines Objekts durch den Müllaufsammler
    gp 6.5.7 Implizit erzeugte Stringobjekte
    gp 6.5.8 Zusammenfassung: Konstruktoren und Methoden
  gp 6.6 Veraltete (deprecated) Methoden/Konstruktoren
  gp 6.7 Vererbung
    gp 6.7.1 Vererbung in Java
    gp 6.7.2 Einfach- und Mehrfachvererbung
    gp 6.7.3 Kleidungsstücke modelliert
    gp 6.7.4 Sichtbarkeit
    gp 6.7.5 Das Substitutionsprinzip
    gp 6.7.6 Automatische und Explizite Typanpassung
    gp 6.7.7 Finale Klassen
    gp 6.7.8 Unterklassen prüfen mit dem Operator instanceof
  gp 6.8 Methoden überschreiben
    gp 6.8.1 super: Aufrufen einer Methode aus der Oberklasse
    gp 6.8.2 Nicht überschreibbare Funktionen
    gp 6.8.3 Fehlende kovariante Rückgabewerte
  gp 6.9 Die oberste aller Klassen: Object
    gp 6.9.1 Klassenobjekte
    gp 6.9.2 Hashcodes
    gp 6.9.3 Objektidentifikation mit toString()
    gp 6.9.4 Objektgleichheit mit equals() und Identität
    gp 6.9.5 Klonen eines Objekts mit clone()
    gp 6.9.6 Aufräumen mit finalize()
    gp 6.9.7 Synchronisation
  gp 6.10 Die Oberklasse gibt Funktionalität vor
    gp 6.10.1 Dynamisches Binden als Beispiel für Polymorphie
    gp 6.10.2 Keine Polymorphie bei privaten, statischen und finalen Methoden
    gp 6.10.3 Konstruktoren in der Vererbung
  gp 6.11 Abstrakte Klassen
    gp 6.11.1 Abstrakte Klassen
    gp 6.11.2 Abstrakte Methoden
    gp 6.11.3 Über abstract final
  gp 6.12 Schnittstellen
    gp 6.12.1 Die Mehrfachvererbung bei Schnittstellen
    gp 6.12.2 Erweitern von Interfaces – Subinterfaces
    gp 6.12.3 Vererbte Konstanten bei Schnittstellen
    gp 6.12.4 Vordefinierte Methoden einer Schnittstelle
    gp 6.12.5 CharSequence als Beispiel einer Schnittstelle
  gp 6.13 Innere Klassen
    gp 6.13.1 Geschachtelte Top-Level-Klassen und Schnittstellen
    gp 6.13.2 Mitglieds- oder Elementklassen
    gp 6.13.3 Lokale Klassen
    gp 6.13.4 Anonyme innere Klassen
    gp 6.13.5 Eine Sich-Selbst-Implementierung
    gp 6.13.6 this und Vererbung
    gp 6.13.7 Implementierung einer verketteten Liste
    gp 6.13.8 Funktionszeiger
  gp 6.14 Gegenseitige Abhängigkeiten von Klassen
  gp 6.15 Pakete


Galileo Computing

6.6 Veraltete (deprecated) Methoden/Konstruktoren  toptop

Während der Phase eines Programms ändert sich die Sicht auf die Methoden und das laufende Angebot eines Objekts oder einer Klasse muss unter Umständen eingeschränkt und verändert werden. Gründe gibt es viele:

Methoden können nicht wirklich plattformunabhängig programmiert werden, wurden aber einmal angeboten. Nun soll die Methode nicht mehr unterstützt werden. (Ein Beispiel ist die Methode stop() eines Threads.)

Die Java-Namenskonvention soll eingeführt werden, und ältere Methodennamen sollen nicht mehr verwendet werden. Das betrifft in erster Linie spezielle set-get-Methoden, die seit Version 1.1 eingeführt wurden. So finden wir beim AWT viele Beispiele dafür. Es heißt zum Beispiel anstatt size() bei einer grafischen Komponente nun getSize().

Entwickler haben sich beim Methodennamen verschrieben. So hieß es in FontMetrics vorher getMaxDecent() und nun getMaxDescent() und im HTMLEditorKit wird insertAtBoundry() zu insertAtBoundary().

Es ist ungünstig, die Methoden jetzt einfach zu löschen, denn andernfalls gibt es Compilerfehler. Eine Lösung ist daher, die Methode beziehungsweise den Konstruktor deprecated zu deklarieren. Deprecated ist ein eigener Dokumentationskommentar, und das sieht etwa so aus (Ausschnitt aus der Klasse java.util.Date):

/**
 * Sets the day of the month of this <tt>Date</tt> object to the 
 * specified value. ….
 *
 * @param   date   the day of the month value between 1-31.
 * @see     java.util.Calendar
 * @deprecated As of JDK version 1.1,
* replaced by <code>Calendar.set(Calendar.DAY_OF_MONTH, int date)</code>.
*/ public void setDate(int date) { setField(Calendar.DATE, date); }

Die Kennung @deprecation gibt an, dass die Methode/der Konstruktor nicht mehr verwendet werden soll. Ein guter Kommentar gibt auch Alternativen an, sofern diese existieren. Die Alternative, die hier genannt wird, ist die Methode set() aus dem Calendar-Objekt. Da der Dokumentationskommentar immer in die generierte Dokumentation kommt, lässt sich daran erkennen, dass eine Methode veraltet ist.

Hinweis   Wenn die Kennung »veraltet« einer Methode anlastet, dann heißt das noch nicht, dass es sie nicht mehr geben muss. Es ist nur ein Hinweis, dass die Methoden nicht mehr verwendet werden sollten. Unterstützung ist nicht mehr gegeben.

Beispiel   Der Compiler gibt bei veralteten Methoden eine kleine Meldung auf dem Bildschirm aus. Testen wir das an der Klasse AlterSack.

Listing 6.17   AlterSack.java

public class AlterSack
{
  java.util.Date d = new java.util.Date( 62, 3, 4 );
}

Jetzt rufen wir ganz normal den Compiler auf.

$ javac AlterSack.java
Note: AlterSack.java uses or overrides a deprecated API.
Note: Recompile with -deprecation for details.

Der Compiler sagt uns schon, was wir machen können: Der Schalter –deprecation zeigt uns mehr. Was wird das wohl sein?

$ javac -deprecation AlterSack.java
AlterSack.java:5: warning: Date(int,int,int) in java.util.Date has been deprecated
  Date d = new Date( 62, 3, 4 );
           ^
1 warning

Die Ausgabe gibt genau die Zeile mit der veralteten Anweisung an. Alternativen nennt er nicht. Allerdings ist schon interessant, dass der Compiler in die Dokumentationskommentare sieht. Er gibt jedoch keine Alternativen an. Eigentlich hat er mit den auskommentierten Blöcken nichts zu tun und überliest jeden Kommentar. Für die speziellen Kommentare gibt es das Extra-Tool Javadoc, das wiederum mit dem Java-Compiler nichts zu tun hat.

Hinweis   Auch Klassen lassen sich als deprecated kennzeichnen (siehe etwa java.io.LineNumberInputStream). Dies finden wir jedoch selten und es sollte vermieden werden.





Copyright © Galileo Press GmbH 2003
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de