Customer Reviews

Bug Patterns In Java

5 star:		(4)
4 star:		(1)
3 star:		(0)
2 star:		(1)
1 star:		(0)

 

 

Bugs. All code has them to one degree or another and they always seem to take twice as long to fix as the original code took to write. This book boils thirteen of the most common bugs down to their root causes and formulates them as 'bug patterns'. Each bug pattern describes how to identify the bug by the symptoms it exhibits, why the bug is occurring, and gives one or more suggestions to fix it and prevent it from occurring again.
If the bug you are searching for isn't among one of the thirteen bug patterns covered, the author also covers a methodical approach to tracking down bugs effieciently and quickly. Suggestions on how to prevent bugs from occurring in various stages of the development cycle are also presented, which are helpful even if you aren't currently searching for a bug in your code. Most of the suggestions are based on the XP development model, but the practices that are important are pointed out so they can be incorporated into any other style of development.
Even though debugging doesn't sound like a fun topic, the author has a very readable style and is able to get you excited about preventing and fixing bugs. The chapters have been very well thought out and the book is broken into topics very well. You can read a chapter in about ten minutes or less and feel like you have a good grasp of the topic covered.
This is a great book to partner with a 'best coding practices' type of book, like 'Practical Java' or 'Effective Java'. Those books are really good at describing how Java should be coded. This book gives examples of why those practices should be followed, and how to quickly get back on track when they aren't and something goes wrong.

Time is a very valuable resource on every project, and this book can help conserve that resource. The first six chapters of the book present defect management within the larger concept of Agile development methods. Chapters 7-20 detail various bug patterns with symptoms, causes, cures, and preventions. The remainder of the book provides some nice resources like a diagnostic checklist, a glossary, a reference list, and an index.

I recognized some of the patterns from the author's column on developerWorks, but the book does a solid of pulling them together to present debugging as a rather orderly and scientific process. The author relies on his real project experience with the DrJava project to illustrate his examples. Various tables are available to link concepts with potential bug patterns or problems to a bug pattern that could be related.

The patterns are explained and depicted with code with each chapter having a summary of the concepts at the end. Tips and variations on the patterns are sprinkled in the text. I found the glossary of particularly helpful. The text is easy to read and the examples are clearly explained. This book and "Bitter Java" may have a good "ROI" as required reading for Java developers.

A great Java resource for programmers of widely varying experience levels. Author found the perfect balance between theory and practical application. There is a wealth of useful information in the chapters devoted to detailed descriptions of the symptoms and cures for the most common and/or most troublesome Java bugs. The book is organized in a very friendly way, making it an excellent reference. I plan on keeping this book very handy.

The author presents a different way to look on bugs and the debugging process. I could recognize most of the bug patterns as regular acquaintances from my daily work. What I liked most was the way he made clear how Java's type system can be used to eliminate certain kinds of bugs but that there's a trade off between static typing and duplication in code. In other words, to remove some sorts of duplication you sometimes have to forgo static typing in Java.

I purchased this book based on the glowing reviews found here, but I must say that my opinion of it is not as positive.

I find it amazing how deeply the pattern mentality has interwoven itself into computer science. While this book does have some useful advice for finding, and more importantly, preventing bugs from appearing in your code in the first place, shoehorning the information into a pattern format served as no more than justification for turning ~30 informative pages into 200. While a book is certainly more than its page count, here is a rough breakdown of how some space is utilized in this book:

- 50 pages explaining testing, eXtreme programming, and bugs in general. While some of this was useful for explaining the bug prevention methods later in the book, much of it was filler, including 7(!) pages of code detailing a questionable kitchen-sink application interface which has absolutely NO bearing on any of the examples or information in the book what so ever

- a 6 page troubleshooting reference that's roughly duplicated by a 10 page diagnostic checklist later in the book, neither of which provides much utility

- 120 pages explain the patterns themselves. While this may sound reasonably meaty, the patterns are often defined multiple times and in very similar ways, are put into a wordy pattern format, and each has an unnecessary summary 1-2 pages long. Not much effort is made to provide differing explanations of a pattern if the original wording doesn't make the meaning clear to you. The cures and preventions within these sections are where the most useful information will be found. Some of the code examples could be shortened and replaced with a second example in a different context.

I also found one of the examples questionable. The author used an example of the difficulties in conveying meaning with a Stack interface. As a Stack is a data structure, would you not create an abstract class instead of an interface in the first place?

Within this same Stack example, the author indicates in a few places that good documentation for this interface would be important to prevent mistakes in the implementation. Would it not be better to refactor the interface so that the implementers have a harder time making these mistakes in the first place? For example, the logic for a pop() method could be implemented by the abstract class and within that pop() method one could execute abstract isEmpty() and removeMostRecentItem() methods (or similar) that the inheritor must implement. In this fashion you encapsulate the logic of the pop() method, allowing the implementer to only be concerned with its own data.

I would only recommend this book to the most voracious reader and would suggest investigating other options instead.

Books that improve my technical communication skills are few and far between; either the advice is too general or it is simply repeating something Gerald Weinberg once said. Still, being able to explain something to a colleague without sounding authoritative is difficult. My belief is that conversations with a colleague should be collegial, and one thing that can set us on equal footing is checklists.

Bug Patterns in Java provides you with a checklist for code reviews and software defect disputes. The best thing about these checklists is that they are non-authoritative. A checklist is just a general static analysis tool. It cannot prove there is a defect or corner case awaiting to be discovered by the end-user. It can, however, non-authoritatively point out patterns in code that appear to be programmer mistakes. What's more, since a checklist is really just a general static analysis tool, you can implement these checklists using automated tools like FindBugs. These tools help provide you with The 2 Minute Answer about the health of your code base.

Now, if you can just run a program to find these mistakes, should you still read Bug Patterns in Java? Absolutely. Just as Martin Fowler's Refactoring is still read by many who love their push-button refactoring features in IDEs, Allen's book should still be read by programmers who use static analysis tools to locate and correct mistakes. The correction half is where Allen shines. He explains exactly what program transformation to do. Moreover, in talking you through the correction, he makes you realize how valuable code reviews are in catching mistakes before they become part of a forward-facing, published API. Allen provides a fantastic vocabulary for describing common bugs in Java, and my belief is that this vocabulary can be cross-pollinated and benefit users of other languages. In particular, Liar View, Dangling Composite, Run-on Initialization and Sabateur Data are phrases I regularly use outside of Java.

Last but not least, most of the chapters are based on an IBM developerWorks series written by Allen. You could read the developerWorks articles by typing in the names of each bug pattern in a search engine. However, if you are not strapped for cash, then it really is worth it to get the book. In my opinion, the format is easier to read, the ideas flow well from one chapter to the next, and Allen definitely spent some extra time sequencing the chapters in the most pedagogical order possible. You are paying for a finished product and world class presentation quality.

Two side notes:

(1) Others have since built upon Allen's work. Sai Zhang published a paper titled "On Identifying Bug Patterns in Aspect-Oriented Programs". It is a really good paper that explains some pitfalls to watch out for, whether you are a programmer or language designer. Templight, a Template Metaprogramming Debugger for C++, was the first effort to provide a way to identify defects in C++ code that takes full advantage of the Turing Complete template system. Problems like infinite recursion and so forth were shown to be identifiable using an automated checklist of sorts. There are many more examples, but these were just the first two I encountered after reading this book. Do your own exploration!

(2) Eric Allen claims he invented the term "bug pattern". Although I don't have any reason to believe he plagiarized the term, Google Book Search suggests that W. Lewis Johnson's book, Intention-Based Diagnosis of Novice Programming Errors (Research Notes in Artificial Intelligence), was the first appearance of the term in the programming field. Thus, credit appears to be owed to Johnson. I just hope that this "bug pattern" term isn't one of those notions that gets lost and re-invented every decade.