|
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.
- 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."
- 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."
- 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) |
|
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.
|