Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Generics, innere Klassen
10 Die Klassenbibliothek
11 Threads und nebenläufige Programmierung
12 Datenstrukturen und Algorithmen
13 Raum und Zeit
14 Dateien und Datenströme
15 Die eXtensible Markup Language (XML)
16 Grafische Oberflächen mit Swing
17 Grafikprogrammierung
18 Netzwerkprogrammierung
19 Verteilte Programmierung mit RMI und Web–Services
20 JavaServer Pages und Servlets
21 Applets
22 Midlets und die Java ME
23 Datenbankmanagement mit JDBC
24 Reflection und Annotationen
25 Logging und Monitoring
26 Sicherheitskonzepte
27 Java Native Interface (JNI)
28 Dienstprogramme für die Java-Umgebung
Stichwort

Download:
- ZIP, ca. 14,1 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java ist auch eine Insel (8. Auflage) von Christian Ullenboom
Programmieren mit der Java Standard Edition Version 6
Buch: Java ist auch eine Insel (8. Auflage)

Java ist auch eine Insel (8. Aufl.)
8., aktual. Auflage, geb., mit DVD
1.475 S., 49,90 Euro
Galileo Computing
ISBN 978-3-8362-1371-4
Pfeil 6 Eigene Klassen schreiben
Pfeil 6.1 Eigene Klassen mit Eigenschaften deklarieren
Pfeil 6.1.1 Attribute deklarieren
Pfeil 6.1.2 Methoden deklarieren
Pfeil 6.1.3 Die this-Referenz
Pfeil 6.2 Privatsphäre und Sichtbarkeit
Pfeil 6.2.1 Für die Öffentlichkeit: public
Pfeil 6.2.2 Kein Public Viewing – Passwörter sind privat
Pfeil 6.2.3 Wieso nicht freie Methoden und Variablen für alle?
Pfeil 6.2.4 Privat ist nicht ganz privat: Es kommt darauf an, wer’s sieht
Pfeil 6.2.5 Zugriffsmethoden für Attribute deklarieren
Pfeil 6.2.6 Setter und Getter nach der JavaBeans-Spezifikation
Pfeil 6.2.7 Paketsichtbar
Pfeil 6.2.8 Zusammenfassung zur Sichtbarkeit
Pfeil 6.3 Statische Methoden und statische Attribute
Pfeil 6.3.1 Warum statische Eigenschaften sinnvoll sind
Pfeil 6.3.2 Statische Eigenschaften mit static
Pfeil 6.3.3 Statische Eigenschaften über Referenzen nutzen?
Pfeil 6.3.4 Warum die Groß- und Kleinschreibung wichtig ist
Pfeil 6.3.5 Statische Variablen zum Datenaustausch
Pfeil 6.3.6 Statische Eigenschaften und Objekteigenschaften
Pfeil 6.4 Konstanten und Aufzählungen
Pfeil 6.4.1 Konstanten über öffentliche statische finale Variablen
Pfeil 6.4.2 Eincompilierte Belegungen der Klassenvariablen
Pfeil 6.4.3 Typ(un)sichere Aufzählungen
Pfeil 6.4.4 Aufzählungen mit enum
Pfeil 6.5 Objekte anlegen und zerstören
Pfeil 6.5.1 Konstruktoren schreiben
Pfeil 6.5.2 Der Default-Konstruktor
Pfeil 6.5.3 Parametrisierte und überladene Konstruktoren
Pfeil 6.5.4 Copy-Konstruktor
Pfeil 6.5.5 Einen anderen Konstruktor der gleichen Klasse aufrufen
Pfeil 6.5.6 Ihr fehlt uns nicht – der Garbage-Collector
Pfeil 6.5.7 Private Konstruktoren, Utility-Klassen, Singleton, Fabriken
Pfeil 6.6 Klassen- und Objektinitialisierung
Pfeil 6.6.1 Initialisierung von Objektvariablen
Pfeil 6.6.2 Statische Blöcke als Klasseninitialisierer
Pfeil 6.6.3 Initialisierung von Klassenvariablen
Pfeil 6.6.4 Exemplarinitialisierer (Instanzinitialisierer)
Pfeil 6.6.5 Finale Werte im Konstruktor und in statischen Blöcken setzen
Pfeil 6.7 Assoziationen zwischen Objekten
Pfeil 6.7.1 Unidirektionale 1:1-Beziehung
Pfeil 6.7.2 Bidirektionale 1:1-Beziehungen
Pfeil 6.7.3 Unidirektionale 1:n-Beziehung
Pfeil 6.8 Vererbung
Pfeil 6.8.1 Vererbung in Java
Pfeil 6.8.2 Spielobjekte modelliert
Pfeil 6.8.3 Implizite Basisklasse java.lang.Object
Pfeil 6.8.4 Einfach- und Mehrfachvererbung
Pfeil 6.8.5 Sichtbarkeit protected
Pfeil 6.8.6 Konstruktoren in der Vererbung und super
Pfeil 6.9 Typen in Hierarchien
Pfeil 6.9.1 Automatische und explizite Typanpassung
Pfeil 6.9.2 Das Substitutionsprinzip
Pfeil 6.9.3 Typen mit dem binären Operator instanceof testen
Pfeil 6.10 Methoden überschreiben
Pfeil 6.10.1 Methoden in Unterklassen mit neuem Verhalten ausstatten
Pfeil 6.10.2 Mit super an die Eltern
Pfeil 6.10.3 Finale Klassen und finale Methoden
Pfeil 6.10.4 Kovariante Rückgabetypen
Pfeil 6.10.5 Array-Typen und Kovarianz
Pfeil 6.11 Dynamisches Binden/Polymorphie
Pfeil 6.11.1 Unpolymorph bei privaten, statischen und finalen Methoden
Pfeil 6.11.2 Polymorphie bei Konstruktoraufrufen
Pfeil 6.12 Abstrakte Klassen und abstrakte Methoden
Pfeil 6.12.1 Abstrakte Klassen
Pfeil 6.12.2 Abstrakte Methoden
Pfeil 6.13 Schnittstellen
Pfeil 6.13.1 Deklarieren von Schnittstellen
Pfeil 6.13.2 Implementieren von Schnittstellen
Pfeil 6.13.3 Markierungsschnittstellen
Pfeil 6.13.4 Ein Polymorphie-Beispiel mit Schnittstellen
Pfeil 6.13.5 Die Mehrfachvererbung bei Schnittstellen
Pfeil 6.13.6 Keine Kollisionsgefahr bei Mehrfachvererbung
Pfeil 6.13.7 Erweitern von Interfaces – Subinterfaces
Pfeil 6.13.8 Vererbte Konstanten bei Schnittstellen
Pfeil 6.13.9 Abstrakte Klassen und Schnittstellen im Vergleich
Pfeil 6.14 Dokumentationskommentare mit JavaDoc
Pfeil 6.14.1 Einen Dokumentationskommentar setzen
Pfeil 6.14.2 Mit javadoc eine Dokumentation erstellen
Pfeil 6.14.3 HTML-Tags in Dokumentationskommentaren
Pfeil 6.14.4 Generierte Dateien
Pfeil 6.14.5 Dokumentationskommentare im Überblick
Pfeil 6.14.6 JavaDoc und Doclets
Pfeil 6.14.7 Veraltete (deprecated) Typen und Eigenschaften


Galileo Computing - Zum Seitenanfang

6.14 Dokumentationskommentare mit JavaDoc Zur nächsten ÜberschriftZur vorigen Überschrift

Die Dokumentation von Softwaresystemen ist ein wichtiger, aber oft vernachlässigter Teil der Softwareentwicklung. Leider, denn Software wird im Allgemeinen öfter gelesen als geschrieben. Im Entwicklungsprozess müssen die Entwickler Zeit in Beschreibungen der einzelnen Komponenten investieren, besonders dann, wenn weitere Entwickler diese Komponenten in einer öffentlichen Bibliothek anderen Entwicklern zur Wiederverwendung zur Verfügung stellen. Um die Klassen, Schnittstellen, Aufzählungen und Methoden sowie Attribute gut zu finden, müssen sie sorgfältig beschrieben werden. Wichtig bei der Beschreibung sind der Typname, der Methodenname, die Art und Anzahl der Parameter, die Wirkung der Methoden und das Laufzeitverhalten. Da das Erstellen einer externen Dokumentation – also einer Beschreibung außerhalb der Quellcodedatei – fehlerträchtig und deshalb nicht gerade motivierend für die Beschreibung ist, werden spezielle Dokumentationskommentare in den Java-Quelltext eingeführt. Ein spezielles Programm generiert aus den Kommentaren Beschreibungsdateien – im Allgemeinen HTML – mit den gewünschten Informationen. [Die Idee ist nicht neu. In den 1980er Jahren verwendete Donald E. Knuth das WEB-System zur Dokumentation von TeX. Das Programm wurde mit den Hilfsprogrammen weave und tangle in ein Pascal-Programm und eine TeX-Datei umgewandelt.]


Galileo Computing - Zum Seitenanfang

6.14.1 Einen Dokumentationskommentar setzen Zur nächsten ÜberschriftZur vorigen Überschrift

In einer besonders ausgezeichneten Kommentarumgebung werden die DokumentationskommentareDoc Comments«) eingesetzt. Die Kommentarumgebung erweitert einen Blockkommentar und ist vor allen Typen (Klassen, Schnittstellen, Aufzählungen) sowie Methoden und Variablen üblich.

Im folgenden Beispiel gibt JavaDoc Kommentare für die Klasse, Attribute und Methoden an.

Listing 6.97 com/tutego/insel/javadoc/Room.java

package com.tutego.insel.javadoc; 
 
/** 
 * This class models a room with a given number of players. 
 */ 
public class Room 
{ 
  /** Number of players in a room. */ 
  private int numberOfPersons; 
 
  /** 
   * A person enters the room. 
   * Increments the number of persons. 
   */ 
  public void enterPerson() { 
    numberOfPersons++; 
  } 
 
  /** 
   * A person leaves the room. 
   * Decrements the number of persons. 
   */ 
  public void leavePerson() { 
    if ( numberOfPersons > 0 ) 
      numberOfPersons--; 
  } 
 
  /** 
   * Gets the number of persons in this room. 
   * This is always greater equals 0. 
   * 
   * @return Number of persons. 
   */ 
  public int getNumberOfPersons() { 
    return numberOfPersons; 
  } 
}

Tabelle 6.3 Die wichtigsten Dokumentationskommentare im Überblick

Kommentar Beschreibung Beispiel

@param

Beschreibung der Parameter

@param a A Value

@see

Verweis auf ein anderes Paket, einen anderen Typ, eine andere Methode oder Eigenschaft

@see java.util.Date

@see java.lang.String#length()

@version

Version

@version 1.12

@author

Schöpfer

@author Christian Ullenboom

@return

Rückgabewert einer Methode

@return Number of elements.

@exception/@throws

Ausnahmen, die ausgelöst werden können

@exception NumberFormatException

{@link Verweis}

Ein eingebauter Verweis im Text im Code-Font. Parameter sind wie bei @see.

{@link java.io.File}.

{@linkplain Verweis}

Wie {@link}, nur im normalen Font

{@linkplain java.io.File}.

{@code Code}

Quellcode im Code-Zeichensatz – auch mit HTML-Sonderzeichen

{@code 1 ist < 2}

{@literal Literale}

Maskiert HTML-Sonderzeichen. Kein Code-Zeichensatz

{@literal 1 < 2 && 2 > 1}

@category

Für Java 7 geplant: Vergabe einer Kategorie

@category Setter



Hinweis Die Dokumentationskommentare sind so aufgebaut, dass der erste Satz in der Auflistung der Methoden und Attribute erscheint und der Rest in der Detailansicht.

/** 
 * Ein kurzer Satz, der im Abschnitt "Method Summary" stehen wird. 
 * Es folgt die ausführliche Beschreibung, die später im 
 * Abschnitt "Method Detail" erscheint, aber nicht in der Übersicht. 
 */ 
public void foo() { }

Weil ein Dokumentationskommentar /** mit /* beginnt, ist er für den Compiler ein normaler Blockkommentar. Die JavaDoc-Kommentare werden oft optisch aufgewertet, indem am Anfang jeder Zeile ein Sternchen steht – dieses ignoriert JavaDoc.


Galileo Computing - Zum Seitenanfang

6.14.2 Mit javadoc eine Dokumentation erstellen Zur nächsten ÜberschriftZur vorigen Überschrift

Aus dem mit Kommentaren versehenen Quellcode generiert ein externes Programm die Zieldokumente. Sun liefert beim SDK das Konsolen-Programm javadoc mit, dem als Parameter ein Dateiname der zu kommentierenden Klasse übergeben wird; aus kompilierten Dateien können natürlich keine Beschreibungsdateien erstellt werden. Wir starten javadoc im Verzeichnis, in dem auch die Klassen liegen, und erhalten unsere HTML-Dokumente.


Beispiel Möchten wir Dokumentationen für das gesamte Verzeichnis erstellen, so geben wir alle Dateien mit der Endung .java an:

$ javadoc *.java

JavaDoc geht durch den Quelltext, parst die Deklarationen und zieht die Dokumentation heraus. Daraus generiert das Tool eine Beschreibung, die in der Regel als HTML-Seite zu uns kommt.

Eclipse-Icon In Eclipse lässt sich eine Dokumentation mit JavaDoc sehr einfach erstellen: Im Menü FileExport ist der Eintrag Javadoc zu wählen, und nach einigen Einstellungen ist die Dokumentation generiert.


Hinweis Die Sichtbarkeit spielt bei JavaDoc eine wichtige Rolle. Standardmäßig nimmt JavaDoc nur öffentliche Dinge in die Dokumentation auf.



Galileo Computing - Zum Seitenanfang

6.14.3 HTML-Tags in Dokumentationskommentaren Zur nächsten ÜberschriftZur vorigen Überschrift

In den Kommentaren können HTML-Tags verwendet werden, beispielsweise <b>bold</b> und <i>italic</i>, um Textattribute zu setzen. Sie werden direkt in die Dokumentation übernommen und müssen korrekt geschachtelt sein, damit die Ausgabe nicht falsch dargestellt wird. Die Überschriften-Tags <h1>..</h1> und <h2>..</h2> sollten jedoch nicht verwendet werden. JavaDoc verwendet sie zur Gliederung der Ausgabe und weist ihnen Formatvorlagen zu.

Eclipse-Icon In Eclipse zeigt die View javadoc in einer Vorschau das Ergebnis des Dokumentationskommentars an.


Galileo Computing - Zum Seitenanfang

6.14.4 Generierte Dateien Zur nächsten ÜberschriftZur vorigen Überschrift

Für jede öffentliche Klasse erstellt JavaDoc eine HTML-Datei. Sind Klassen nicht öffentlich, muss ein Schalter angegeben werden. Die HTML-Dateien werden zusätzlich mit Querverweisen zu den anderen dokumentierten Klassen versehen. Daneben erstellt JavaDoc weitere Dateien:

  • index-all.html. Liefert eine Übersicht aller Klassen, Schnittstellen, Ausnahmen, Methoden und Felder in einem Index.
  • overview-tree.html. Zeigt in einer Baumstruktur die Klassen an, damit die Vererbung deutlich sichtbar ist.
  • allclasses-frame.html. Zeigt alle dokumentierten Klassen in allen Unterpaketen auf.
  • deprecated-list.html. Bietet eine Liste der veralteten Methoden und Klassen.
  • serialized-form.html. Listet alle Klassen auf, die Serializable implementieren. Jedes Attribut erscheint mit einer Beschreibung in einem Absatz.
  • help-doc.html. Zeigt eine Kurzbeschreibung von JavaDoc.
  • index.html. JavaDoc erzeugt eine Ansicht mit Frames. Das ist die Hauptdatei, die die rechte und linke Seite referenziert. Die linke Seite ist die Datei allclasses-frame.html. Rechts im Frame wird bei fehlender Paketbeschreibung die erste Klasse angezeigt.
  • stylesheet.css. Formatvorlage für HTML-Dateien, in der sich Farben und Zeichensätze einstellen lassen, die dann alle HTML-Dateien nutzen.
  • packages.htm. Eine veraltete Datei. Sie verweist auf die neuen Dateien.

Galileo Computing - Zum Seitenanfang

6.14.5 Dokumentationskommentare im Überblick Zur nächsten ÜberschriftZur vorigen Überschrift

JavaDoc-Kommentare kann der Entwickler in den Block setzen, so wie @param oder @return zur Beschreibung der Parameter oder Rückgaben, andere auch in den Text, wie {@link} zum Setzen eines Verweises auf einen anderen Typ oder eine andere Methode. Tags der ersten Gruppe heißen Block-Tags, die anderen Inline-Tags. Bisher erkennt das JavaDoc-Tool die folgenden Tags (ab welcher Version, steht in Klammern): [http://tutego.de/go/javadoctags]

  • Block-Tags: @author (1.0), @deprecated (1.0), @exception (1.0), @param (1.0), @return (1.0), @see (1.0), @serial (1.2), @serialData (1.2), @serialField (1.2), @since (1.1), @throws (1.2), @version (1.0)
  • Inline-Tags: {@code} (1.5), {@docRoot} 1.3, {@inheritDoc} (1.4), {@link} (1.2), {@linkplain} (1.4), {@literal} (1.5), {@value} (1.4)

In Java 6 ist kein Tag hinzugekommen. Es gibt aber einiges auf der Liste, was als JavaDoc-Tag in Java 7 hinzukommen soll.

Beispiele

Eine externe Zusatzquelle geben wir wie folgt an:

@see <a href="spec.html#section">Java Spec</a>.

Verweis auf eine Methode, die mit der beschriebenen Methode verwandt ist:

@see String#equals(Object) equals

Von @see gibt es mehrere Varianten:

@see #field 
@see #method(Type, Type,...) 
@see #method(Type argname, Type argname,...) 
@see #constructor(Type, Type,...) 
@see #constructor(Type argname, Type argname,...) 
@see Class#field 
@see Class#method(Type, Type,...) 
@see Class#method(Type argname, Type argname,...) 
@see Class#constructor(Type, Type,...) 
@see Class#constructor(Type argname, Type argname,...) 
@see Class.NestedClass 
@see Class 
@see package.Class#field 
@see package.Class#method(Type, Type,...) 
@see package.Class#method(Type argname, Type argname,...) 
@see package.Class#constructor(Type, Type,...) 
@see package.Class#constructor(Type argname, Type argname,...) 
@see package.Class.NestedClass 
@see package.Class 
@see package

Dokumentiere eine Variable. Gib einen Verweis auf eine Methode an:

/** 
 * The X-coordinate of the component. 
 * 
 * @see #getLocation() 
 */ 
int x = 1263732;

Eine veraltete Methode, die auf eine Alternative zeigt:

/** 
 * @deprecated  As of JDK 1.1, 
 * replaced by {@link #setBounds(int,int,int,int)} 
 */

Statt HTML-Tags wie <tt> oder <code> für den Quellcode zu nutzen, ist {@code} da viel einfacher.

/** 
 * Compares this current object with another object. 
 * Uses {@code equals()} an not {@code ==}. 
 */

Galileo Computing - Zum Seitenanfang

6.14.6 JavaDoc und Doclets Zur nächsten ÜberschriftZur vorigen Überschrift

Die Ausgabe von JavaDoc kann den eigenen Bedürfnissen angepasst werden, indem Doclets eingesetzt werden. Ein Doclet ist ein Java-Programm, das auf der Doclet-API aufbaut und die Ausgabedatei schreibt. Das Programm liest dabei wie das bekannte JavaDoc-Tool die Quelldateien ein und erzeugt daraus ein beliebiges Ausgabeformat. Dieses Format kann selbst gewählt und implementiert werden. Wer also neben dem von JavaSoft beigefügten Standard-Doclet für HTML-Dateien Framemaker-Dateien (MIF) oder RTF-Dateien erzeugen möchte, muss ein eigenes Doclet programmieren oder kann auf Doclets unterschiedlicher Hersteller zurückgreifen. Die Webseite http://www.doclet.com/ listet zum Beispiel Doclets auf, die Docbook generieren oder UML-Diagramme mit aufnehmen.

Daneben dient ein Doclet aber nicht nur der Schnittstellendokumentation. Ein Doclet kann auch aufzeigen, ob es zu jeder Methode eine Dokumentation gibt oder ob jeder Parameter und jeder Rückgabewert korrekt beschrieben ist. Vor dem Durchbruch der Annotationen in Java 5 waren Doclets zur Generierung zusätzlicher Programmdateien und XML-Deskriptoren populär. [XDoclet (http://xdoclet.sourceforge.net/) generiert aus Anmerkungen in den JavaDoc-Tags Mappings-Dateien für relationale Datenbanken oder Dokumente für Enterprise JavaBeans.]


Galileo Computing - Zum Seitenanfang

6.14.7 Veraltete (deprecated) Typen und Eigenschaften topZur vorigen Überschrift

Während der Entwicklungsphase einer Software ändern sich immer wieder Methodensignaturen, oder Methoden kommen hinzu oder fallen weg. Gründe gibt es viele:

  • Methoden können nicht wirklich plattformunabhängig programmiert werden, wurden aber einmal so angeboten. Nun soll die Methode nicht mehr unterstützt werden. (Ein Beispiel ist die Methode stop() eines Threads.)
  • Die Java-Namenskonvention soll eingeführt, ä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. Nun heißt es zum Beispiel statt size() bei einer grafischen Komponente 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 Veraltetes hat sich im Laufe der Zeit genug angesammelt. In Java 6 sind über 334 Methoden, 20 Konstruktoren, 54 Variablen/Konstanten, 21 Klassen (zuzüglich 4 Exceptions), 17 Schnittstellen (viele aus CORBA), 3 Annotationstypen und ein Annotationselement veraltet.


Es ist ungünstig, die Methoden jetzt einfach zu löschen, weil es dann zu Compilerfehlern kommt. Eine Lösung wäre daher, die Methode beziehungsweise den Konstruktor als deprecated zu deklarieren. Deprecated ist ein eigener Dokumentationskommentar; das sieht dann etwa folgendermaßen 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 @deprecated gibt an, dass die Methode/der Konstruktor nicht mehr verwendet werden soll. Ein guter Kommentar zeigt auch Alternativen auf, sofern welche vorhanden sind. Die hier genannte Alternative ist die Methode set() aus dem Calendar-Objekt. Da der Kommentar in die generierte API-Dokumentation übernommen wird, erkennt der Entwickler, dass eine Methode veraltet ist.


Hinweis Wenn eine Methode als »veraltet« markiert ist, heißt das noch nicht, dass es sie nicht mehr geben muss. Es ist nur ein Hinweis darauf, dass die Methoden nicht mehr verwendet werden sollten und Unterstützung nicht mehr gegeben ist.


Compilermeldungen bei veralteten Methoden

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

Listing 6.98 OldSack.java

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

Jetzt rufen wir ganz normal den Compiler auf.

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

Der Compiler sagt uns, dass der Schalter -deprecation weitere Hinweise gibt.

$ javac -deprecation OldSack.java 
OldSack.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. Eigentlich hat er mit den auskommentierten Blöcken nichts zu tun und überliest jeden Kommentar. Zur Auswertung der speziellen Kommentare gibt es ja 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.


Die Annotation @Deprecated

Seit Java 5 gibt es Annotationen, die zusätzliche Modifizierer sind. Eine Annotation @Deprecated (groß geschrieben) ist vorgegeben und ermöglicht es ebenfalls, Dinge als veraltet zu kennzeichnen. Dazu wird die Annotation wie ein üblicher Modifizierer etwa für Methoden vor den Rückgabetyp gestellt. Sun hat die obengenannte Methode setDate() mit dieser Annotation gekennzeichnet, wie der folgende Ausschnitt zeigt:

/** ... 
 * @deprecated As of JDK version 1.1, 
 * replaced by <code>Calendar.set(Calendar.DAY_OF_MONTH, int date)</code>. 
 */ 
@Deprecated 
public void setDate(int date) { ... }

Der Vorteil der Annotation @Deprecated gegenüber dem JavaDoc-Tag besteht darin, dass die Annotation auch zur Laufzeit sichtbar ist. Liegt vor einem Methodenaufruf ein @Deprecated-Tester, so kann dieser die veralteten Methoden zur Laufzeit melden. Bei dem JavaDoc-Tag übersetzt der Compiler das Programm in Bytecode und gibt zur Compilerzeit eine Meldung aus, im Bytecode selbst gibt es aber keinen Hinweis.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Java ist auch eine Insel





Java ist auch eine Insel
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Tipp
Zum Katalog: Coding for Fun





 Coding for Fun


 Buchempfehlungen
Zum Katalog: Objektorientierte Programmierung





 Objektorientierte
 Programmierung


Zum Katalog: Einstieg in Eclipse 3.4






 Einstieg in
 Eclipse 3.4


Zum Katalog: Java 6 lernen mit Eclipse






 Java 6 lernen
 mit Eclipse


Zum Katalog: NetBeans Platform 6






 NetBeans
 Platform 6


Zum Katalog: Java und XML






 Java und XML


Zum Katalog: Visual C# 2008






 Visual C# 2008


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


Zum Katalog: C++ von A bis Z






 C++ von A bis Z


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2009
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, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de