Errata

Java: The Good Parts

Errata for Java: The Good Parts

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 Note Update

Version Location Description Submitted by Date submitted
Printed, Page 13
On code esample

Hello,

On the code example for class CheckBatter you have private Batter.AtBatResult[] testData but it is never used.

You also have an object testBatters which never is set or passed.

I guess you have omitted some code for not being relevant at the time but I think it may be confusing not having working code.

Or am I missing something else?

Thanks.

Miguel Gonzalez  Jan 26, 2014 
PDF Page 57
example code

The previously confirmed errata for the print version with the following description is also true of the current ebook version.

"
In text you explain that you don't have a readIn.close(); in the constructor but only in the finalize method. But in the example code you have a readIn.close(); right after the object has been read.

Note from the Author or Editor:
The line
readIn.close();
in the try block of the constructor should be removed.
"

tehgeekmeister  Sep 27, 2011 
Printed Page 148
code sample

The boolean variable "done" is not declared volatile nor accessed using any other synchronization action, so there is no guarantee that its updated value will be visible to the thread calling the isDone method.

Fix:

private volatile boolean done = false;

Joe Bowbeer  Nov 24, 2011 
Printed Page 148
code sample

[After further inspection, please replace the previous report with the following -JAB]

The boolean variable "done" is not declared volatile nor is it accessed using any other synchronization action, so there is no guarantee that its updated value will be visible to the thread calling the isDone method.

The simplest fix for this is to add "volatile" to the declaration:

private volatile boolean done = false;

The same criticism also applies to "roster" and this can also be addressed by adding "volatile".

In addition, as a matter of good concurrent style, the "fromHost" and "forTeam" instance variables assigned in the constructor should be declared final.

At this point I think some mention of FutureTask is required. Ideally, RosterRetriever would be a FutureTask -- a class that already provides thread-safe isDone and get() methods.

Joe Bowbeer  Nov 24, 2011 
Printed Page 154
atBat code sample

The "base3" and "base4" cases in the switch statement are missing their terminating "break" statements, resulting in invalid results in these cases.

Joe Bowbeer  Nov 24, 2011 
Printed Page 159
atBat code sample

The "base3" and "base4" cases in the switch statement are missing their terminating "break" statements, resulting in invalid results in these cases.

Joe Bowbeer  Nov 24, 2011