Errata

The method will fail if there's a change in daylight saving between the first and the
second date. the result of the following lines should be 122:

Date d1 = new GregorianCalendar(1999, 11, 31, 23, 59).getTime();

Date d2 = new GregorianCalendar(2000, 04, 01, 23, 59).getTime();

long diff = d2.getTime() - d1.getTime();
System.out.println("Difference between " + d2 + "
" + (diff / (1000 * 60 * 60 * 24))
+ " days.");

The solution could be something like:

TimeZone t = new SimpleTimeZone(0, "SIMPLE");
GregorianCalendar c1 = new GregorianCalendar(t);
GregorianCalendar c2 = new GregorianCalendar(t);

c1.set(1999, 11, 31, 23, 59);
Date d1=c1.getTime();

c2.set(2000,04,01,23,59);
Date d2 = c2.getTime();

The example of 6.10 is a bit misleading, as it fails to point a
serious trap in the result of the Calendars get() method: while
Calendar counts from one for most entries, months start at zero..

Example:

Calendar calendar = new GregorianCalendar(2001,Calendar.DECEMBER,24);
System.out.println("month/day/year: "
+calendar.get(Calendar.MONTH) +"/"
+calendar.get(Calendar.DAY_OF_MONTH)+"/"
+calendar.get(Calendar.YEAR));

outputs "month/day/year: 11/24/2001".

Thus Java celebrates X-mas at 11/24!

The line where the Iterator is created is wrong in the HashMap example.

It says:
Iterator it = h.values().iterator();

with results:
Key Mountain View, CA; Value null
Key White Plains, NY; Value null
Key Mountain View, CA; Value null
Key Mountain View, CA; Value null
Key Redmond, WA; Value null
Key Sebastopol, CA; Value null
Key Los Angeles, CA; Value null

It should be:
Iterator it = h.keySet().iterator();

It's rare for a clone() method to declare that it throws
CloneNotSupportedException, and doing so makes it much harder for the users
of the class to copy objects because they must handle the "impossible"
exception. The only time doing so is necessary is if the class itself does
not implement Cloneable although subclasses are allowed to implement
Cloneable, or if the clone() method called on a field may throw a
CloneNotSupportedException.

A more cookbook way to write the clone() method is the following:

public Object clone() {
try {
return super.clone();
} catch (CloneNotSupportedException e) {
throw new InternalError();
}
}

or if some Cloneable fields need to be cloned:

public Object clone() {
ThisClass tc;
try {
tc = (ThisClass) super.clone();
} catch (CloneNotSupportedException e) {
throw new InternalError();
}
if (field != null)
tc.field = (FieldClass) field.clone();
return tc;
}

or if the class itself does not implement Cloneable or it clones a field that
may throw CloneNotSupportedException:

public Object clone() throws CloneNotSupportedException {
ThisClass tc = (ThisClass) super.clone();
if (field != null)
tc.field = (FieldClass) field.clone();
return tc;
}

The following sentence is a mis-statement:
"Script-based languages like Arabic and Indian languages, and pictographic languages
like Chinese, Japanese and Korean each have many more than 256 characters, the
maximum that can be represented in an eight-bit byte."

The Korean language is NOT an pictographic language like Chinese and Japanese--it is
a phoenetic language with 11 vowels and 14 consonents.

The paragraph refers to the methods copyTestFile() and copyDataFile(), which aren't shown in example 9-1.

NOTE: this error is also present in the downloadable source code.

it reads:

....
// The modem sends an extra blank line by way of a prompt.
// Here we read and discard it.
xyz String junk = os.readLine();
if (junk.length() != 0) {
System.err.print("Warning unexpected response: ");
System.err.println(junk);
}
....

see the line marked "xyz" -
a) readLine is deprecated, so its use should be avoided
b) object "os" is a PrintStream - these do not conventionally possess a
"readLine" method

btw - I'm using JDK 1.3, and a surprising amount of code is coming up as
deprecated.

I believe there are some problems with recipe 12.4.

First, the y coordinate of Graphics.drawstring() is the
coordinate of the baseline. Therefore, I don't understand
why you are subtracting the leading which is just the
inter-line spacing. If you want the baseline to be centered,
they the y-coordinate should just be "getSize().height / 2".
If you want the text to actually be centered, then I think
you need something like:
(getSize().height - fm.getHeight()) / 2 + fm.getLeading() + fm.getAscent()

In addition, your font picture is, at best, very misleading. The "height" is
equal to "ascent + decent + leading". Check
out the FontMetrics javadoc.

The variable clientSocket is declared within the synchronized section, and it appears the scope
is confined to that section as well. So when it is used outside of this section (i.e. within the
next 6 lines below), the compiler flags it with a "cannot resolve symbol" error.

It can be fixed by declaring clientSocket at the top of the try block, and then just assigning the
variable with the synchronized block:

...
try {
Socket clientSocket;
...
synchronized(servSock) {
clientSocket = servSock.accept();
}
...

This example (AppletMethods.java) is not available in the 9780596001704src.zip
file. (There IS a link to the file in the html index.)

this states that the code for another project "would be like fig 18-1 except
that you would need a doGet instead of a doPost."

Fig 18.1, derived from example 18.1 does in fact use a doGet, rather than a
doPost as stated.

The line 'import com.darwinsys.util' must be added to the eample MessageNode.java

It took me 2 hours to find out that the code for the
manifest-file works only when written with a capital C in Class

So:

NOT: Main-class: HelloWorld
BUT: Main-Class: HelloWorld

In the public ThreadsDemo2 constructor, a new thread is created and named...

t = new Thread(this);
t.setName(m + " printer thread");

But, the thread is never started!

t.start();

"Extending Thread is recommended." Doug Lea's authoritative book Concurrent
Programming in Java gives several concrete reasons why implementing
Runnable should be preferred over extending Thread. The consensus among Java
programmers is that creating a new thread should be done by implementing
Runnable, but creating a new *type* of thread should be done by extending
Thread.

The statement "only one thread at a time is allowed to run the given code"
is true only for static syncronized methods. For non-static methods, any
number of threads may run the given code at the same time, as long as each
of the threads calls the method on a different object. Synchronization locks
are held on objects, not on methods.

"Making the method synchronized means that any invocations of it will wait
if one thread has already started running the method." Again, this is
true only
if the method is static, or if all threads call the method on the same
object. It is not true for non-static methods when different threads call
the method on different objects.