Errata
Submit your own errata for this product.
The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question
| Version |
Location |
Description |
Submitted By |
| Printed |
Page 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)'
|
Anonymous |
| Printed |
Page 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.
|
Anonymous |
| Printed |
Page 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.
|
Anonymous |
| Printed |
Page 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.
|
Anonymous |
| Printed |
Page 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.)
|
Anonymous |
