From Productiveprogrammer

[edit] Book Errata & Improvements

(by page of occurrence)

[edit] I:84 ( DRY: Impedance Mismatch )

Java Bean Generator Code: Using Groovys Triple Quotation Marks and no tabs would have made the write_properties method much easier to read. Imports could have be deduced from the type mapping.

[edit] E:85 ( DRY: Impedance Mismatch )

The Java class shown is no DAO but a Java Bean Pojo. DAO is a pattern for encapsulating the data access layer. It would be nice having a simple ibatis-CRUD-DAO generated as well.

[edit] E:139 ( Occam's Razor )

The remove method is called with parameter 0, but the explanation states it is 2. The following sentence

In this case, Java autoboxes the integer 2 into an Integer object, looks in the list to see if there is an element with the content of 2, fails to find one, and doesn't remove anything from the list.

should be changed with

In this case, Java autoboxes the integer 0 into an Integer object, looks in the list to see if there is an element with the content of 0, fails to find one, and doesn't remove anything from the list.

[edit] I:145 (Angry Monkeys)

Underscored test method names. It would have been great if a reference to this section was given at the first appearance of these test method names in the book. They troubled me up to this page. There is the great TestDox plugin for IntelliJ IDEA for generating testcases and methods and having an outline view which renders camel case method names to space separated sentences.

[edit] E:150 (Java & Reflection)

catching Throwable is bad practice as this also silently catches Errors (like OutOfMemory and other critical stuff). Catching Exception is enough.

[edit] I:153 (Fluent interfaces)

Recipe.for "Spicey bread"
.mix 200.grams.of Flour 
.with 1.lb.of Nutmeg

Would also have been a nice syntax.

[edit] I:154 (Fluent Interfaces)

Test: This is hardly a unit test, rather an integration test as the ingredients are not tested separately. Edge cases are also missing. except for the "add"-setup the "expected" array is not used for any expectation assertions.

[edit] I: 156 (SLAP - Composed Method)

A reference to Kent's Implementation Patterns would have been nice. As this is the more recent book on the topic. There he elaborates quit a lot on this pattern. As well as symmetry which is also a principle in his (value-principle-pattern system).

E: calling c.close on the connection in case of an Exception (c is still null) will yield a NPE in the finally block

[edit] E:168 (Zero-Based Arrays)

The equivalence to C example is quite flawed. The book states that arr[1] is equivalent to *arr + (1 * sizeof(int)), which is evaluated as (*arr) + (1 * sizeof(int)), and thus gives us the value of element zero added to the size of an int, not at all what is claimed. Since arr is a pointer to int, arr[1] is really equivalent to *(int*)((char*)arr + (1 * sizeof(int))), or more simply, *(arr + 1). The book should use the latter, as it eliminates the irrelevant sizeof, and directly illustrates one reason for zero-based indexing in C.

And of course the allocation isn't C at all:

int[] arr = malloc (sizeof(int), 2 ); // what's in the book, which isn't C
int* arr = malloc( sizeof (int) * 2 ); // correct
int* arr = calloc( sizeof (int), 2 ); // also correct

[edit] E:185 (Keeping Behavior in Code)

"Term papers, This is easier to read because it has much less XML-based noise in it, like curly braces"

Probably meaning: like angled brackets.

On the same page, when talking about builders, it says that Ruby builders were inspired by Groovy builders. Wasn't it the other way around? (No it wasn't)