Java Cookbook, 2nd Edition
by Ian F. Darwin

Unconfirmed error reports are from readers.  They have not yet been 
approved or disproved by the author or editor and represent solely the
opinion of the reader.

This page was updated February 27, 2008.

Here's a key to the markup:
	[page-number]: serious technical mistake
	{page-number}: minor technical mistake
	<page-number>: important language/formatting problem
	(page-number): language change or minor formatting problem
	?page-number?: reader question or request for clarification


UNCONFIRMED errors and comments from readers:

[7] Example 1-1, Raw 6;
During the run of the example system puts out following error message: 'Exeption in thread "main" java.lang.ArrayIndexOutOfBoundExeption: 0
at Factorial.main(Factorial.java:6)'


{195}  last paragraph;
hashSet requires that an objects' hashCode() method returns the 
same value as another object which is considered equal as well as 
its equals method returning tue. The hashCode method is called first, 
only if this returns the same value as one already in the set is the 
equals method called.


{242-243} Singleton section;
Serialization of a singleton class isn't handled (extra objects could be created via serialization). Also (should this be a separate submission?) in the variation with making all methods static it is claimed "but this works only if methods do not need to share state"--which is incredibly false. (static fields?)

Thirdly: singletonList() etc. are not singleton classes. They return a new instance every time they're called. emptyList() (or EMPTY_LIST) etc. are what you were looking for.


(710) near bottom;
On p. 708 MAX was set to 10 and it looked like the list should be held to that size, but according to the text here on 710, "List size now 118" and "I'm happy to report that all is well with this."

Hopefully either the code could be changed to not seem to claim that the list will have an enforced maximum size or the "all's well" could be changed to mention that while there's been success with the deadlocking issues, threading is complex enough that problems remain, and look "here in another O'Reilly book" for how to deal with that.

I'm assuming above that the code doesn't actually lock, but examining it suggests that if the list is full (and the code enforces this) or if the list is empty, the producers or the consumers respectively might not get to the "if (done) break;" part of the code before waiting again.


[713] Recipe 24.8, example 24-13, the last lines of this example;
Last line attempts to end the operation by setting the "done" flag to true.

// End of simulation - shut down gracefully
pc.done = true;

This flag controls both producer and consumer loops, and is a concurrent variable. It is written to by the main thread, and read by both producer and consumer threads.

Access to this flag is not synchronized. While writing a boolean value is defined as an atomic operation, this doesn't mean the value will be visible to any other threads.

In short, either access to this field should be synchronized or it should be marked "volatile". An alternative is to inject "poison objects" into the queue and have consumers terminate gracefully upon reading them.

(This error doesn't appear in example 24-12, where access to the field is properly synchronized.)