6.16 Veraltete (deprecated) Methoden/Konstruktoren
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 setXXX()/getXXX()-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(). |
| Hinweis Die veralteten Dinge haben sich im Laufe der Zeit angesammelt; in Java 5 sind über 300 Methoden/Konstruktoren, etwas mehr als 50 Variablen/Konstanten, 21 Klassen (zuzüglich 4 Excptions) und 16 Schnittstellen.
|
Es ist ungünstig, die Methoden jetzt einfach zu löschen, denn dann 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.70
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.
|
|
