The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
| Version |
Location |
Description |
Submitted By |
Date submitted |
Date corrected |
| Printed |
Page xii-xiii
The following text was added to the preface |
Please let us know about any errors you find, as well as your
suggestions for future editions, by writing to:
O'Reilly & Associates, Inc.
101 Morris Street
Sebastopol, CA 95472
1-800-998-9938 (in the U.S. or Canada)
1-707-829-0515 (international/local)
1-707-829-0104 (FAX)
You can also send us messages electronically. To be put on the
mailing list or request a catalog, send email to:
info@oreilly.com
To ask technical questions or comment on the book, send email to:
bookquestions@oreilly.com
We have a web site for the book, where we'll list examples, errata,
and any plans for future editions. You can access this page at:
http://www.oreilly.com/catalog/9781565924185/
For more information about this book and others, see the O'Reilly web site:
http://www.oreilly.com
The authors welcome your feedback about this book, especially if
you spot errors or omissions that we have made. You can contact us
at scott.oaks@sun.com and henry.wong@sun.com.
|
Anonymous |
|
Mar 01, 2000 |
| Printed |
Page 16
In the 6th line of the code example, change |
boolean shouldRun; // Set to false to stop thread
to:
volatile boolean shouldRun; // Set to false to stop thread
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 17
After the paragraph that concludes |
much like the state it would be in if the thread were waiting for I/O to
occur.
the following sentence was added:
See Appendix A for a discussion of the volatile keyword.
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 26
|
The first paragraph of Chapter 2 used to read:
As in earlier versions of Java, we have a TimerThread
object that is started and stopped when the applet is
started and stopped. In Java 2, the applet's stop()
method does more than just stop the TimerThread: it also
checks to make sure the thread actually has stopped.
It now reads:
Just like the earlier versions, we have a TimerThread
object that is started and stopped when the applet is
started and stopped. In this newer version, the applet's
stop() method does more than just stop the TimerThread: it
also checks to make sure the thread actually has stopped.
|
Anonymous |
|
May 01, 1999 |
| Printed |
Page 29
In the 2nd line of the code example, change |
boolean shouldRun; // Set to false to stop thread
to:
volatile boolean shouldRun; // Set to false to stop thread
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 30
In the 6th line of the code example, change |
boolean shouldRun; // Set to false to stop thread
to:
volatile boolean shouldRun; // Set to false to stop thread
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 34
|
Line 16 of Animate class. The line that used to read:
t = null;
Is now commented out:
// t = null;
This class is meant to show a problem by not running correctly.
|
Anonymous |
|
May 01, 1999 |
| Printed |
Page 47
In the last paragraph, change the phrase |
making the method atomic
to:
serializing access to the method
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 52
After the paragraph that concludes |
will contain the bits set by the second thread.
the following sentence was added:
However, atomicity does not insure thread communication; see the
discussion of volatile in Appendix A.
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 81
|
The first paragraph used to read:
"The main difference between these two methods is that the
interrupted() method resets the value of the flag to false. The
isInterrupted() method does not change the value of the flag. Note
that the interrupted() method is static and operates on the current
thread, whereas the isInterrupted() method is dynamic and must be
executed on a thread object."
[The last sentence of that paragraph was removed, along with the code line
Thread.currentThread().isInterrupted() The next paragraph continues as
written:]
"The point behind these methods is that the..."
|
Anonymous |
|
Jun 01, 2000 |
| Printed |
Page 81
In the code example, the start of the run() method looks |
like this:
public void run() {
Object o;
while (true) {
synchronized(data) {
if (isInterrupted())
return;
while (data.size() == 0) {
try {
|
Anonymous |
|
Jun 01, 2000 |
| Printed |
Page 82
At the end of the first paragraph (after "checks the interrupted |
flag.") the following sentence was added:
"In order to prevent the interrupt from arriving at any other time,
we must only send the interrupt from a thread that has synchronized
on the data object that was passed into the constructor."
|
Anonymous |
|
Jun 01, 2000 |
| Printed |
Page 83
In the 20th line of the code example, change |
private boolean done = false;
to:
private volatile boolean done = false;
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 103
In the 8th line of the code example, change |
boolean shouldStop = false;
to:
volatile boolean shouldStop = false;
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 110
In the 7th-10th line of the code example, change |
private byte result[]; // Buffer
private int reslen; // Buffer length
private boolean EOF; // End-of-file indicator
private IOException IOError; // I/O exceptions
to:
private volatile byte result[]; // Buffer
private volatile int reslen; // Buffer length
private volatile boolean EOF; // End-of-file indicator
private volatile IOException IOError; // I/O exceptions
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 114
In the 4th-7th line of the code example, change |
private byte result[]; // Buffer
private int reslen; // Buffer length
private boolean EOF; // End-of-file indicator
private IOException IOError; // I/O exceptions
to
private volatile byte result[]; // Buffer
private volatile int reslen; // Buffer length
private volatile boolean EOF; // End-of-file indicator
private volatile IOException IOError; // I/O exceptions
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 146
|
At the top of the page, the ThreadA run method used to read:
public void run(){
synchronized(someObject){
wait();
}
someObject.methodA();
}
The line:
wait() was changed to:
someObject.wait();
|
Anonymous |
|
Jun 01, 2000 |
| Printed |
Page 154
In Chapter 6, Line 9 of CPUSupport class, |
"System.loadLibrary("CPUSupportSolaris");"
Deleted extra indent.
|
Anonymous |
|
May 01, 1999 |
| Printed |
Page 159
In the 6th line of the code example, change |
boolean shouldRun = false;
to:
volatile boolean shouldRun = false;
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 162
In the 6th line of the code example, change |
boolean shouldRun = false;
to:
volatile boolean shouldRun = false;
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 170
The last line of the code example, change |
boolean shouldRun = true;
to:
volatile boolean shouldRun = true;
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 180
On the 5th line of the code example, change |
public boolean shouldRun = false;
to:
public volatile boolean shouldRun = false;
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 185.7
|
The text used to read:
"The first try clause in the run() method protects us when the
thread that was running at priority 4 exited; the second clause
protects us when a thread has been stopped from another thread.
I believe that the responsibilities have been reversed - i.e. it is
the 2nd try clause that handles the exiting thread and the 1st clause
that handles the stopped thread."
This sentence was removed. The start of the next sentence (now the first
sentence in the paragraph) now reads:
"Note that in the run() method, when the exception is thrown we need
to remove the thread..."
|
Anonymous |
|
Jun 01, 2000 |
| Printed |
Page 258
In Chapter 9, the bottom paragraph, the reference to |
"LoopSelfHandler" has been changed to "SelfLoopHandler."
|
Anonymous |
|
May 01, 1999 |
| Printed |
Page 277
On the 5th line of the code example, change |
boolean shouldStop = false;
to:
volatile boolean shouldStop = false;
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 285
On the 1st line of the code example, change |
public boolean shouldRun;
to:
public volatile boolean shouldRun = true;
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 292
|
Last paragraph. The line that used to read:
boolean allowThreadSuspension(boolean b) (Java 1.1 and above only)
Now reads:
boolean allowThreadSuspension(boolean b) (Java 1.1 only)
|
Anonymous |
|
May 01, 1999 |
| Printed |
Page 303
The following was added to the bottom of the page |
The Volatile Keyword
As we mentioned in Chapter 3, the act of setting the value of a variable
(except for a long or a double) is atomic. That means there is generally no
need to synchronize access simply to set or read the value of a variable.
However, Java's memory model is more complex than that statement indicates.
Threads are allowed to hold the values of variables in local memory (e.g.
in a machine register). In that case, when one thread changes the value of
a variable, another thread may not see the changed value. This is particularly
true in loops that are controlled by a variable (like the shouldRun variable
that we use to terminate threads): the looping thread may have already loaded
the value of the variable into a register and will not necessarily
notice when another thread sets that variable to false.
There are many ways to deal with this situation. You can synchronize
on the object that contains the control variable -- or better yet,
you can provide accessor methods for the control variable (such as we do
with the busyflag variable in our BusyFlag class). Or you can mark the variable
as volatile, which means that every time the variable is used, it must be read
from main memory.
In versions of the VM through 1.2, the actual implementation of Java's memory
model made this a moot point: variables were always read from main memory.
But as VMs become more sophisticated, they will introduce new memory models
and optimizations, and observing this rule will be increasingly important.
|
Anonymous |
|
Dec 01, 1999 |
| Printed |
Page 319
The following index entry was added |
|
Anonymous |
|
Dec 01, 1999 |