Rating: 
Summary: Break some rules!
Review: A genuine treat! Witty, but erudite -- but easy to read, like a "spoonful of sugar." With Java being such an error-free language by design, how do you write a book like Debugging Java? You look for where the errors are. They aren't in the source code nearly so often as they are in the development processes. Surely this is why Mitchell doesn't include a ton of source code. It's not a book that lists a lot of boring subroutines you can cut and paste for your website. There have been 2,000 other books that do that! This unique book teaches you the Mastery of Java. One reviewer said it is for beginners only. I strongly--strongly disagree. It is primarily for Experts, and Would-be Experts. It is for people who need to become, as the author states, Java Masters. Beginners copy source code from books. Experts expand the horizons and write their own. Therein lies the problem. How do you write code that can be, "Guaranteed to Specs., Forever!"? Mitchell guarantees his code that way, and lo, he shows you how he does it. He sure showed me a lot. I feel 50% better about my Java now, and people already consider me a guru. Little did they know how shakey I really was. Want to be the best? Devour this book! Even if you're a VB or a Cobol programmer, devour this book. Dev-X loves it. Java Pro loves it (3/01), saying it belongs on every programmer's shelf. I think it belongs open, next to the keyboard. I did what another reviewer suggested. I bought nine copies for my people and made it required reading. Way to go, Mitch!
Rating: 
Summary: Is He Serious?
Review: A while back I picked up 'Debugging VB' and didn't think much of it. At first I thought 'Debugging Java' was better, but the author completely blew his credibility on three counts: 1. Not only does he recommend using MS Word as a Java IDE, he goes to some length to provide macros and so on to show how to achieve context-sensitive highlighting and so on. In fact, at the back of the book, several pages are devoted to this very thing. 2. At one point he writes with pride about how he whipped up a 'report generator' in Basic that cranked out 25 copies of boilerplate COBOL. Precisely the kind of code that Java's inheritance and object composition paradigms are intended to avoid. Some people never learn! 3. In a similar vein, he also takes about a faux Javadoc he developed that cranked out 1" of documentation in half a day. This fellow seems to prefer quantity over quality. On the plus side, this book had a better-than-average discussion of the various IDE's (other than Word!), and is worth a quick peruse to see what they all look like, if you haven't already.
Rating:
Summary: There is a useful part
Review: Although it was probably not worth the price of admission his discussion on preventing bugs was useful. Essentially, if you have 1 week to do 2 weeks work you will produce buggy code. To avoid deadline stress like this he recommends a system for estimating work that consists of estimating what it would take if you could write it off the top of your head and giving it a factor from 0 to 5? for how unaquainted with the component techniques you are. Then raise your intitial estimate to this power to get your estimate for how long you will take for this task. However, I agree with all the other criticisms. 2 stars. Not absolutely aweful but I could write better.
Rating:
Summary: There is a useful part
Review: Although it was probably not worth the price of admission his discussion on preventing bugs was useful. Essentially, if you have 1 week to do 2 weeks work you will produce buggy code. To avoid deadline stress like this he recommends a system for estimating work that consists of estimating what it would take if you could write it off the top of your head and giving it a factor from 0 to 5? for how unaquainted with the component techniques you are. Then raise your intitial estimate to this power to get your estimate for how long you will take for this task. However, I agree with all the other criticisms. 2 stars. Not absolutely aweful but I could write better.
Rating: 
Summary: Excellent, but a little outdated in places
Review: Debugging Java is a disappointing read for me. This book seems to be a general book about debugging, while trying hard to introduce some elements of Java. 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. :(
Rating: 
Summary: Only old-timers and newbies will like this book
Review: First let me say I liked the writing style and it was enjoyable to read. I was able to finish the book cover to cover in 3 days of casual reading. I did get something useful out of the book. He talked about right-brain versus left-brain activity which I found interesting and helpful for my job. 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.
Rating:
Summary: Use MS Word to Write Java!
Review: I try to look on the bright side of every book I read, and the bright side of this book is that everyone at the office got a good laugh when the CTO brought it in. The author talks about the advantages to editing java files with MS Word over other editors meant entirely for text document writing (Wordperfect, and another editor that I'd never heard of, but which, I was told, was popular in the '80s) . It also talks about writing word macros to help, and has a small section on how you may have problems with Word appending '.doc' to your java source files. Aside from choice of editing tools, the content itself is poor. This is not a book for anyone who has programmed before, it is not a book for those who are trying to learn Java, and it doesn't talk about debugging Java in any real sense, so I can't imagine who this book is for. I am amazed, however, at the fact that I see these 'Debugging' books in prominent places at many bookstores. I haven't looked at any of the other 'Debugging' series, but either the publisher has tremendous clout to get these books put on shelves, or _Debugging Java_ is the black sheep of the 'Debugging' family.
Rating:
Summary: Excellent book for beginners, but with lots of mistakes
Review: This book is called Debugging Java, and it does have some Java specific content (like discussions of Java specific debugging tools), but its content can be applied to any language. Being a veteran programmer most of the tactics evangelized by this book I had already learned (many the "hard" way). Interestingly one technique that I find extremely useful, walking through each new line of code in the debugger, wasn't mentioned at all. Beginning to intermediate programmers will benefit the most. While reading this book, be very careful about trusting the examples and descriptions because there are a lot of errors in the text and the examples. Some are obvious and trivial (like the "test stub" claiming that "a = 5; b = 5; a = b = 10;" will result in "a == 5" on page 235) others are less obvious and can cloud the points. Most of the philosophy discussed, however, is dead on. All-in-all a little depressing that in a book about bugs and testing the thing the book needed most was better editing. I was disapointed to find that almost the last 100 pages of the book is fairly useless appendices (lists of Java applications that undoubtedly was out of date before the book hit the shelves, for example) including 20 pages of Word macros that would make Word into a questionable programmer's editor. If you can't afford a "real" programmer's editor like CodeWright, my current favorite, at least get a free version of EMACS, which is available on pretty much every platform. My opinion.
Rating:
Summary: Excellent book for beginners, but with lots of mistakes
Review: This book is called Debugging Java, and it does have some Java specific content (like discussions of Java specific debugging tools), but its content can be applied to any language. Being a veteran programmer most of the tactics evangelized by this book I had already learned (many the "hard" way). Interestingly one technique that I find extremely useful, walking through each new line of code in the debugger, wasn't mentioned at all. Beginning to intermediate programmers will benefit the most. While reading this book, be very careful about trusting the examples and descriptions because there are a lot of errors in the text and the examples. Some are obvious and trivial (like the "test stub" claiming that "a = 5; b = 5; a = b = 10;" will result in "a == 5" on page 235) others are less obvious and can cloud the points. Most of the philosophy discussed, however, is dead on. All-in-all a little depressing that in a book about bugs and testing the thing the book needed most was better editing. I was disapointed to find that almost the last 100 pages of the book is fairly useless appendices (lists of Java applications that undoubtedly was out of date before the book hit the shelves, for example) including 20 pages of Word macros that would make Word into a questionable programmer's editor. If you can't afford a "real" programmer's editor like CodeWright, my current favorite, at least get a free version of EMACS, which is available on pretty much every platform. My opinion.
Rating:
Summary: What a piece of (...) !!
Review: This book is shock full of the authors ramblings about how he fixed
this and that problem when he was a COBOL or VB programmer. Plus it
is crammed with code that is just plain wrong. It often doesn't
even compile. It is such a disgrace that a book about code quality
contains so much idiotic programming errors. I threw away the book
in disgust after the third code example in a row was illegal Java.
I dispise myself for again picking it up and finishing it. It was
such a waste of time. If you want to learn how to write quality
code, then go read the first XP book: Extreme Programming Explained: Embrace Change.
| 
