Guido Krüger's Web Service · Go To Java 2 · ISBN 3-8273-1370-8
Fehler/Änderungen
Beschreibung

Download

Bestellung

Fehler/Änderungen

Aufgaben

Leserstimmen

Java 2 lernen

Startseite

2. Auflage

Seit Dezember 2004 gibt es die vierte Auflage von "Go To Java 2". Sie hat den Titel "Handbuch der Java-Programmierung, 4. Auflage" und steht zum Download auf

www.javabuch.de

Die ersten Auflagen gibt es nicht mehr! Bitte ändert eure Links entsprechend!


Papierversionen

Bezeichnung Erschienen Erkennbar an... Bemerkungen
1. Nachdruck Juli 1999 Unterhalb der Verlagsbezeichnung "Addison-Wesley" auf Seite 3 steht "An imprint of Pearson Education". Entspricht (bis auf eine Ausnahme (s.u.)) der Version 1.0.4 der Online-Version.
Erstauflage Februar 1999 Unterhalb der Verlagsbezeichnung "Addison-Wesley" auf Seite 3 steht "An imprint of Addison Wesley Longman, Inc". Entspricht der Version 1.0 der Online-Version.

Online-Versionen

Aktuelle Version: 1.0.5

Known bugs
(15.10.2000)
  • Im letzten Satz in Kapitel 7.7.3 (im Buch auf Seite 180) muß es "Sammlerstueck" heißen, und nicht "Sammlerobjekt" wie irrtümlich angegeben.
  • In Listing 7.29 (im Buch auf Seite 178) hat sich ein Fehler eingeschlichen. In Zeile 011 muß der Datentyp "int" lauten (statt "double" wie im Buch angegeben).
  • In Listing1208 gibt es mit dem JDK 1.3RC1 in den Zeilen 39, 42, 45, usw. Fehler beim Kompilieren, da das Case-Label nicht als konstant angesehen wird. Dies kann behoben werden, indem die Konstanten nicht aus der Variablen cal, sondern direkt über ihre Klasse Calendar qualifiziert werden: Calendar.SUNDAY, Calendar.MONDAY, usw...
  • In Abschnitt 11.2.4 muß es im ersten Textabsatz (im Buch auf Seite 255, 10. Zeile von unten) "equals liefert true, wenn das aktuelle String-Objekt und anObject gleich sind.". Im Buch steht "identisch" statt "gleich".

  • Bei der Beschreibung der Methode Thread.sleep in Abschnitt 10.2.4 (im Buch auf Seite 229, Zeile 10 ff.) wurde beschrieben, daß sleep nach jedem Aufruf eine InterruptedException auslöst. Dies stimmt nicht (und steht auch im Widerspruch zu den ausführlichen Erläuterungen im Abschnitt 10.2.2). Der Satz "Die Kapselung des Aufrufs..." sollte ersetzt werden durch: "Die Kapselung des Aufrufs von Thread.sleep innerhalb eines try-catch-Blocks ist erforderlich, weil sleep während der Wartezeit eine Ausnahme des Typs InterruptedException auslösen kann.". Der Rest des Absatzes kann unverändert bleiben.

  • Bei der Beschreibung der for-Schleife in Abschnitt 6.3.3 (im Buch auf Seite 147, letzter Punkte der Aufzählung) wurde angegeben, daß der update-Ausdruck nur eine einzige Komponente enthalten darf. Das stimmt natürlich nicht; er darf - wie auch der init-Ausdruck - aus mehreren Teilen bestehen. Der Satz "Im Gegensatz zum init-Ausdruck darf der update-Ausdruck nicht aus mehreren Komponenten bestehen" sollte daher gestrichen und durch folgenden Satz ersetzt werden: "Wie der init-Teil darf auch der update-Teil aus mehreren Ausdrücken bestehen.".

  • Die bei der nachfolgenden Beschreibung der gelabelten break- und continue-Anweisungen verwendeten Beispiele sind unbrauchbar (im Buch auf den Seiten 148 und 149). Der gesamte Abschnitt wurde überarbeitet und mit einem besseren Beispiel versehen.

  • In Listing 7.23 (im Buch auf Seite 171) fehlt bei der Definition der Konstanten der zugehörige Datentyp. Statt "private static final STEUERSATZ = 18.9;" muß es in Zeile 003 "private static final double STEUERSATZ = 18.9;" heißen.
1.0.5
(31.10.1999)
  • Die Methode finalize der Klasse Object wird im Buch versehentlich als öffentlich bezeichnet. Tatsächlich wird sie in der Klasse Object mit dem Attribut protected deklariert. Der erste Satz des zweiten Absatzes von Abschnitt 7.2.7 (im Buch auf Seite 161 unten) sollte daher wie folgt geändert werden: "Ein Destruktor wird als geschützte parameterlose Methode mit dem Namen finalize definiert:". Auch die erste Zeile in dem folgendem Listing 7.16 (im Buch auf Seite 162 oben) sollte entsprechend angepaßt werden: "protected void finalize()".

  • Bei der Beschreibung des Überlagerns von Methoden ist es mitunter sinnvoll, zwischen überlagerter (verdeckter) und überlagernder Methode (diejenige, die verdeckt) auch bei der Wortwahl zu unterscheiden (insbesondere, wenn beide Bedeutungen in einem gemeinsamen Kontext auftauchen). Da im Buch lediglich der Terminus "überlagert" verwendet wird, sollten folgende Textteile angepaßt werden:

    • Abschnitt 7.3.2, zweiter Absatz, letzter Satz (im Buch auf Seite 164): "Wurde eine Methode überlagert, wird beim Aufruf der Methode auf Objekten dieses Typs immer die überlagernde Version verwendet."

    • Gleicher Abschnitt, letzter Absatz vor dem Unterabschnitt "Dynamische Methodensuche", zweitletzter Satz (im Buch auf Seite 165 oben): "Zukünftig würde dadurch in allen Objekten vom Typ ZweisitzerCabrio bei Aufruf von alter die überlagernde Version, bei allen Objekten des Typs Auto oder Cabrio aber die alte Version verwendet werden."

    • Gleicher Abschnitt, zweiter Satz im Unterabschnitt "Aufrufen einer verdeckten Methode" (im Buch auf Seite 165 unten): "Aufrufe von x beziehen sich immer auf die überlagernde Variante."

    • Abschnitt 18.2.2, Unterabschnitt "Anonyme Klassen", dritter Absatz, letzter Satz (im Buch auf Seite 423 oben): "Zum Instanzierungszeitpunkt erfolgt die Definition der überlagernden Methode keyPressed, in der der Code zur Reaktion auf das Drücken der Taste ESC untergebracht wird."

    • Abschnitt 23.1, vorletzter Absatz, zweiter Satz (im Buch auf Seite 556): "Eine überlagernde Version kann hier natürlich ein beliebig komplexes Darstellungsverhalten realisieren."

  • Bei der Besprechnung der Methode showDocument in Abschnitt 25.4.3 (im Buch auf Seite 622) wurde die Variante mit zwei Parametern falsch beschrieben. Der drittletzte und der vorletzte Absatz ("In seiner einfachsten Form..." und "Handelt es sich dagegen...") sollten durch folgende Absätze ersetzt werden:

    "In seiner einfachsten Form erwartet showDocument lediglich einen einzigen Parameter, nämlich die Adresse der Zielseite. Hier muß ein gültiges URL-Objekt angegeben werden, also eine komplette Adresse mit Dienst, Host-Name, Verzeichnis und Datei. In der zweiten Variante kann zusätzlich ein target angegeben werden, also das Sprungziel innerhalb der ausgewählten Datei. Hier können die Standard-HTML-Targets "_self", "_parent", "_top" und "_blank" sowie alle benutzerdefinierten Sprungmarken verwendet werden."

    "Soll statt einer absoluten eine relative Adresse angegeben werden, also beispielsweise eine andere Web-Seite aus demselben Verzeichnis oder aus einem seiner Unterverzeichnisse, muß das URL-Objekt mit einem erweiterten Konstruktor instanziiert werden. Zusätzlich zur Angabe des relativen URL-Strings ist als erstes Argument ein Kontext-URL anzugeben, der das Basisverzeichnis für das zweite Argument vorgibt. Mit Hilfe der Methoden getCodeBase und getDocumentBase der Klasse Applet kann beispielsweise das Stammverzeichnis des Applets bzw. der HTML-Seite ermittelt werden. Als zweites Argument muß dann lediglich der Dateiname relativ zu diesem Verzeichnis angegeben werden."

    Zusätzlich sollte der letzte Satz dieser Seite (der letzte Satz des nächsten Absatzes) wie folgt geändert werden: "In diesem Fall wird das = entfernt und der interne URL nicht absolut, sondern unter Verwendung des erweiterten Konstruktors relativ zur aktuellen Web-Seite angelegt."

  • Bei der Angabe des Wertebereichs von Fließkommazahlen in Tabelle 4.1 (im Buch auf Seite 105) wurde der Exponent falsch angegeben. Statt +/-3.4028234738 muß es natürlich +/-3.40282347 * 1038 heißen. Entsprechendes gilt für den Wertebereich von double eine Zeile tiefer.

  • Bei der Erläuterung der Themen Default-Konstruktoren und Konstruktorenverkettung in den Abschnitten 7.2.6 und 7.3.3 haben sich einige Ungenauigkeiten eingeschlichen.

    1. Der Unterabschnitt "Default-Konstruktoren" (im Buch auf den Seiten 160 unten und 161 oben) sollte wie folgt umgeschrieben werden:

      "Falls eine Klasse überhaupt keinen expliziten Konstruktor besitzt, wird beim Anlegen des Objekts ein parameterloser default-Konstruktor zur Verfügung gestellt. Seine einzige Aufgabe besteht darin, den parameterlosen Konstruktor der Superklasse aufzurufen. Enthält eine Klassendeklaration dagegen ausschließlich parametrisierte Konstruktoren, wird kein default-Konstruktor erzeugt, und die Klassendatei besitzt letzendlich überhaupt keinen parameterlosen Konstruktor."

    2. Der letzte Absatz im nachfolgenden Unterabschnitt "Verkettung von Konstruktoren" ("Wird ein Konstruktor ... gibt es einen Compiler-Fehler", im Buch auf Seite 161) kann abgekürzt werden zu:

      "Wird ein Konstruktor in einem anderen Konstruktor derselben Klasse explizit aufgerufen, muß dies als erste Anweisung innerhalb der Methode geschehen. Steht der Aufruf nicht an erster Stelle, gibt es einen Compiler-Fehler."

    3. Der dritte Absatz von Abschnitt 7.3.3 ("Falls als erste Anweisung im Konstruktor kein Aufruf von...", im Buch auf Seite 166) sollte am Ende um folgenden Satz ergänzt werden:

      "Das ist genau dann der Fall, wenn in der Superklassendeklaration lediglich parametrisierte Konstruktoren angegeben wurden und daher ein parameterloser default-Konstruktor nicht automatisch erzeugt wurde."

  • In Listing 24.14 (im Buch auf Seite 598) wird noch die Methode size() aufgerufen. Sie ist veraltet und sollte durch getSize() ersetzt werden, damit die "deprecated"-Warnungen verschwinden.

  • In Abschnitt 7.8.1 (im Buch auf Seite 181 unten) wird geschrieben, daß die Wrapperklassen zur Simulation von call-by-reference verwendet werden können. Das stimmt leider nicht! Zwar werden Objekte tatsächlich per Referenz übergeben, aber da die vordefinierten Wrapper-Klassen von Java unveränderlich sind (immutable), läßt sich das übergebene Objekt innerhalb der Methode nicht ändern. Der erste Absatz der Aufzählung ("Da Objekte im Gegensatz...") sollte daher komplett gestrichen werden.

    Zusätzlich sollten hinter dem nun ersten Absatz der Aufzählung ("Das Paket java.util...") zwei neue Punkte in die Aufzählung eingefügt werden:

    • "Da Objektreferenzen den Wert null haben können, kann die Verwendung der Wrapper-Klassen beispielsweise bei der Datenbankprogrammierung nützlich sein. Damit lassen sich primitive Feldtypen darzustellen, die NULL-Werte enthalten können."

    • "Das Reflection-API (siehe Kapitel 31) verwendet Wrapper-Klassen zum Zugriff auf Membervariablen oder Methodenargumente primitiver Typen."

    Der ursprünglich fehlerhafte Absatz sollte nun als Warnhinweis in invertierter Form hinter die Aufzählung gestellt werden (und steht damit unmittelbar vor dem Absatz "Wrapper-Klassen existieren zu allen numerischen Typen und...", im Buch auf Seite 182 oben):

    "Da Objektparameter im Gegensatz zu primitiven Typen per Referenz übergeben werden, bieten die Wrapper-Klassen prinzipiell die Möglichkeit, Methodenparameter per call by reference zu übergeben, und damit Änderungen von primitiven Parametern an den Aufrufer zurückzugeben. In der Praxis funktioniert das allerdings nicht, denn alle vordefinierten Wrapper-Klassen sind unveränderlich (immutable). Als Alternative bietet es sich lediglich an, eigene Wrapper-Klassen zu definieren, die eine Möglichkeit zum Ändern des eingepackten Wertes bieten."

  • Auch im 1. Nachdruck der Papierversion ist der Fehler bei den Fließkommaliteralen (s.u.) in Abschnitt 4.2.4 (im Buch auf Seite 108, letzter Satz vor Tabelle 4.3) nicht vollständig korrigiert. Statt "NEGATIVE_INFINITY bzw. NaN entsteht..." sollte dort "NaN entsteht..." stehen. Die Online-Versionen enthalten diesen Fehler nicht.
1.0.4
(3.8.1999)
  • In Abschnitt 6.3.3 (im Buch auf Seite 147) wird die Deklaration von Variablen im Initialisierungsteil einer for-Schleife mit C++ verglichen. Die Aussage "im Gegensatz zu C++ erstreckt sich die Sichtbarkeit und Lebensdauer aber nicht auf die ganze Methode, sondern..." war zwar für frühere Versionen von C++ korrekt. Bezogen auf ANSI C++ stimmt sie allerdings nicht mehr, denn hier verhält sich C++ nun analog zu Java.

  • Im Buch ist in Abschnitt 27.6.2 das falsche Listing abgedruckt (im Buch auf Seite 673). Statt Listing2706.java sollte dort Listing2707.java stehen. Die Online-Versionen enthalten diesen Fehler nicht.

  • Bei den Fließkommaliteralen in Abschnitt 4.2.4 (im Buch auf Seite 108) wurde die Bedeutung der Konstanten NaN und POSITIVE_INFINITY bzw. NEGATIVE_INFINITY vertauscht. Der letzte Satz vor Tabelle 4.3 muß demnach lauten: "NaN entsteht beispielsweise bei der Division durch 0, POSITIVE_INFINITY bzw. NEGATIVE_INFINITY sind Zahlen, die größer bzw. kleiner als der darstellbare Bereich sind.".

  • In Abschnitt 10.4.2 (im Buch auf Seite 240) wird im letzten Absatz vor Listing 10.10 fälschlicherweise auf Kapitel 7 verwiesen. Statt "...die aus Kapitel 7 (Seite 151) bekannte..." muß dort "...die in Abschnitt 31.2.2 (Seite 785) erläuterte..." stehen.
1.0.3
(10.5.1999)
  • In Kapitel 7 wird zur Altersberechnung mehrfach das Jahr 1996 verwendet. Das entspricht dem Erscheinungsjahr der ersten Auflage des Buchs. Es sollte an folgenden Stellen durch 1999 ersetzt werden:

    • Seite 155, 17. Zeile v.u., Listing 7.6
    • Seite 155, 12. Zeile v.u., "...Differenz von 1996 und dem..."
    • Seite 156, 15. Zeile v.o., Listing 7.8
    • Seite 164, 4. Zeile v.u., Listing 7.21
    Zudem muß auf Seite 155, 5. Zeile v.u. "...die Zahl 6 auf..." durch "...die Zahl 9 auf..." ersetzt werden.

  • In Kapitel 7 wurde in Listing 7.30 (im Buch auf Seite 179) das Schlüsselwort "Interface" versehentlich groß geschrieben. Korrekt lautet die erste Zeile des Listings public interface Sammlerstueck.

  • Im Buch sind in folgenden Listings Einrückungen fehlerhaft:

    • Seiten 226/227: Listing 10.3
    • Seiten 423/424: Listing 18.4 (leicht fehlerhaft)
    • Seiten 425/426: Listing 18.5 (leicht fehlerhaft)
    • Seiten 433/434: Listing 19.1 (leicht fehlerhaft)
    • Seiten 435-437: Listing 19.2 (leicht fehlerhaft)
    • Seiten 440/441: Listing 19.3 (leicht fehlerhaft)
    • Seiten 443-446: Listing 19.4 (leicht fehlerhaft)
    • Seiten 448/449: Listing 19.5 (leicht fehlerhaft)
    • Seiten 453-456: Listing 19.6
    • Seiten 541/542: Listing 22.13 (Umbruch in Zeile 016)
    • Seite 660: Listing 27.2 (leicht fehlerhaft)
    • Seite 687: Listing 28.2
    • Seite 787: Listing 31.1 (nur Zeile 053)
    • Seite 789: Listing 31.2 (nur Zeile 011)

    In der Online-Version sind diese Fehler meist nicht vorhanden, sie beeinflussen auch nicht die inhaltliche Korrektheit der Listings.

1.0.2
(9.3.1999)
  • Im Buch ist in Abschnitt 9.2.2 das falsche Listing abgedruckt (im Buch auf Seite 211). Statt Listing0903.java sollte dort RTErrorProg2.java stehen. Die Online-Versionen enthalten diesen Fehler nicht.

  • In Abschnitt 6.2.1 muß es im zweiten Absatz des Abschnitts "Bedeutung" in der zweiten Zeile ", andernfalls anweisung2" statt ", andernfall ausdruck2" heißen (im Buch auf Seite 142, 2. Zeile v.u.).

  • In Abschnitt 5.7.2 muß es im zweiten Absatz "Nicht-String-Operand" statt "Nicht-String-Operator" heißen (im Buch auf Seite 130, 14. Zeile v.u.). Eine Zeile weiter muß es dann "mit dem anderen Operanden" statt "mit dem anderen Operator" heißen.
1.0.1
(2.2.1999)
  • Im Abschnitt 20.5 muß der Klassenname in der Marginalspalte java.awt.Button heißen (im Buch auf Seite 471, 14. Zeile v.o.).

  • Im Abschnitt 22.8 muß der Klassenname in der Marginalspalte java.awt.event.ItemEvent heißen (im Buch auf Seite 538, 7. Zeile v.u.).

  • Im Abschnitt 27.7.1 muß der Klassenname in der Marginalspalte java.lang.Comparable heißen (im Buch auf Seite 674, 12. Zeile v.u.).

  • Im Abschnitt 32.2.1 muß der Klassenname in der Marginalspalte java.net.InetAddress heißen (im Buch auf Seite 819, 1. und 6. Zeile v.o.).
1.0
(31.1.1999)
Buchversion fertiggestellt.

Weitere Informationen zu den jeweiligen Änderungen finden sich im Buch.


© 1995-2004 Guido Krüger - Last updated 27 Dec 2004 - Back to top-level page