Debugging Java: Troubleshooting for Programmers [Paperback]

The book is well organized for the most part, although there are places where the author goes off on a tangent. Although Word can be used to prevent certain kinds of bugs, the placement of this and other less conventional techniques merited a section of their own.

My other complaint with this book is that some of the specific information regarding IDE's and such are quite out-of-date. While Visual Cafe was just recently pulled from the market, other IDE's have been gone for sometime, and anyone who has been around Java for more than a couple weeks will have heard of the IDE's and other Java tools listed in the book. But in the end, some of the information is valuable enough that I'll be re-reading portions of this every year as a reminder and checkup on my coding practices.

Debugging Java seems to have some glaring errors, For example, in P150

------------------------------------------------------------
str1 = "ABC";
str2 = "ABC";
System.out.println(str1 == str2);

The above prints false, because str1 is not str2 regardless of contents.

------------------------------------------------------------

Are you sure???

The book also spend another chapter talking about using MS Word as a good specialized editors. Hur ... which programmer would use MS Word as their editor?

Appendix A lists some resources for Java, eg. IDE, debugging tools etc. This took up 30 pages. No wonder the book is so thick ...

By far, this is the most disappointing book I have read. :(

I've made the mistake of reading Extreme programming and Refactoring BEFORE reading this book. So for example in this book the author spends great detail on how to count in a large switch case statement how many case: elements you should have and how to quickly check it. If you've read Refactoring by Fowler you would instantly hear alarms in your head telling you your NOT using OO corectly and that this bad code should be refactored. If you want a good OO/Design Patterns book I would recomend Cooper's book. You better understand Design Patterns if your going to code in Java or you will have a tough time when it comes to I/O and Swing classes.

Two finally points to make on the downside of this book.
1. The author mentions 'goto' and does not correctly tell the history of why the word is reserved. James Gosling at OPSLA on year informed the audience that a technical writer was documenting 'goto' and wanted him to explain it. When James did a grep against the code base he saw it used 10 times of which only 3 where valid in his opinion. James then decided it was easier to remove it than it was to have it documented. James felt that continue and break statements handled all cases that goto were being used in the system.

2. The exception model in C++ is just plain broken and the author does not do a good job of explaining what Java did to fix this problem. In a very large C++ system any 3rd party library could throw an exception that is un-advertised. Exceptions in C++ are checked at runtime. The Java compiler checks exceptions at compile time. In java you could never add a 3rd party jar file and have an exception thrown that is not advertised in the interface of the class or method.

Java is an OO language and to debug in Java you better know OO and you better understand threads and java.object or your going to have a long night. The author should have started here and delved deaper instead of wasting paper on MS Word and Word macros for coding.

Ah...
Before I forget. If you read the book PLEASE don't use /** QQQ*/
as a tag in your code. If you've got JBuilder use /** todo */ or something non-cryptic to document coding in progress comments.