Customer Reviews

Bitter Java

5 star:		(18)
4 star:		(9)
3 star:		(2)
2 star:		(11)
1 star:		(2)

 

 

I had high hopes for this book based on an endorsement from a friend of mine. What I found was this book, while presenting some minimally useful information was peppered with errors and generally poor.

The good points: the author is a fairly good writer, presenting technical information in a semi-interesting fashion. If you don't know what MVC is, or the Command pattern, there is some useful information here (read the caveats below).

The bad points: what good information is here is better presented in many other design patterns books. The book's information is really for junior level people and yet is so full of errors (and uncompilable code!) that it is likely to be frustrating to just such a beginner. Be prepared for coding errors such as:

public Integer i = 0;

If you don't know why this is wrong, get a well edited book. What's more, the author borrows liberally from freely available code out on the web (good) but can't even reformat the code to be consistent with his own (bad, bad, bad!). So you are treated to at least a half dozen different code formatting peculiarities during the code examples. As well, he is inconsistent about how he presents code, in some cases presenting a whole class, in other cases just a snippet without any context of how it might be employed in a class (again, a problem for the target audience).

Frankly don't get this book unless you've already tried some of the better books out there like:

Design Patterns
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

or

one of the many Java design patterns books (I won't recommend one in particular, since I've only skimmed them, not read any straight through).

"I like learning from my mistakes ..., but I would much rather learn from your mistakes." -- Bruce Tate, "Bitter Java", page 313.

If design patterns are success stories, anti-patterns are lessons you can learn from other people's failures. Consultants like Bruce Tate make money to support his Kayak hobby by identifying anti-patterns in customer projects and offering valuable advices to refactor them. Now, he has offered his advices for all of us for [$] in Manning's new book "Bitter Java" (ISBN 193011043X).

So, what exactly are anti-patterns? Are they only relevant to software architects? Now, consider the following questions:

Do you know that Java applications might have memory leaks too? Have you written 500 line servlets or JSP pages? Do you notice that your container managed EJBs cannot scale when the load is high? If any of the answers is "yes", Java anti-patterns might be more relevant to you than you think.

This book avoids discussing anti-pattern in academic terms. Instead, it gives a real world server side Java application that an inexperienced developer is likely to write and then refactors it all the way through various anti-patterns to a scalable, maintainable solution. Tate not only teaches you the anti-patterns you encounter, he also gives a valuable example on the software development process to refactor an poorly written existing application.

The author uses extensive real world code examples throughout the book to explain the problems and why we should avoid them. Like all other Manning books, the code examples are well commented and annotated in the main text. Although the anti-pattern examples in the book are mainly in the context of J2EE application servers, the author has done a good job to generalize the problems and illustrate how they might appear in other Java applications. Anti-patterns such as memory leak, synchronized cache read/write and round tripping can have negative impacts on a big range of Java applications.

The author is very good at comparing the relative merits of different approaches, technologies and patterns. There are numerous comparison tables throughout the article and they are great resources for readers who just want a quick summary of what to do/what not to do in a given circumstance. Examples of those helpful tables include the different EJB types comparison on page 241 and the all anti-patterns listing at the end of the book.

In general it is a great book well worth the time and money for all Java developers, especially if you are working on J2EE projects. Of course, there are also things that could be improved.

1. While I liked the kayak stories, some people might find them distracting. However, those side line stories are well separated from the main content using italic fonts. So, this is really not a problem.

2. In chapter 8, I wish the author could talk more about the trade-offs between performance and code maintainability in CMP (Container Managed Perssistency) EJBs. He could also talk a bit about JDO (Java Data Objects), which is a lightweight entity bean alternative.

3. In chapter 3 and 4, the author mentioned that Jakarta Strut's "action" is essentially his "command" pattern. But since Strut is such a popular tool, it would still be nice to give examples on how to use Strut to achieve MVC model along with the "command" pattern example.

I think it's clear that Java has reached maturity. However, many programmers have felt how hard it is to see Java kicking and screaming through childhood and adolescence. There's often a right way to write Java code, and many many wrong ways. This book is for those who have loved and lost, and who don't mind trying again.

One of the common criticisms of Erich Gamma's seminal "Design Patterns" (or more relevantly, William Brown's "Antipatterns") is that they make for fun reading, but the ideas are awfully hard to put into practice. Well, this book connects current design theory to a useful implementation, as long as you are programming in Java. There is a slight disconnect between some of the Java examples and strict theory (for example, Gamma would never have seen fit to include a mini-antipattern like "Too Many Web Page Items"... too basic for his style), so this book feels more like the lessons learned (the hard way) from a Java consultant rather than a formal textbook. Which of course is what it is.

On the down side, I thought I would like the "adventure stories" that start each chapter, but in the end they feel like they are a too-obvious attempt to reach the Boulder Colorado Yuppie Java Programmer market. Another criticism is that some of the figures are too basic to deserve space on the page and seem to be placed there to add some color and break up the text. Comments like "I suppressed a triumphant smile and again reviewed the [other programmer's bad] code" or "we have compiled... all of the good programming examples. They work." feel like a lecture from a "white knight" programmer parachuting in to save your deranged Java project. Bruce Tate is Smarter Than You.

...and he is, or at least he's smarter than *me*. I've never worked on a large-scale Java project, and a lot of the topics he mentions (cache management and preventing database connection thrashing, for example) are things I've never thought of trying. Other sections like the short course in good Internet coding standards in chapter 2 seem a bit brief (and to be fair, the author admittedly suggests skipping to chapter 3 for some programmers). Luckily, I love the clear summaries of the antipatterns at the end of each chapter for those programmers like me who like to read from the back of a book to the front. But for all reader types, this book contains many great lessons that should be learned before ever starting a coding project.

If your Java project isn't going well, or if you're just starting another Java "free fall", I highly recommend reading this book. At its best, the antipatterns in this book seem like common sense - but don't let that deter you from thinking that you need to read this book. You can learn this stuff before you start coding, when you're in the middle of a bad Java project, or you can learn it the hard way like the author. It's your choice. I guess I was expecting a little more bitterness from the Java and not the author, but sometimes life is hard.

While reading this book, I kept referring colleages past and present to information within as questions about "how should I..." popped up. It's an excellent set of reminders about lessons learned, and old lessons applied to current technology.

The content is very accessible to the intermediate programmer and budding architect, and the examples of implementations with problems followed by refactored improvements highly valuable. It's much better to learn learn from mistakes without making them all yourself, as the book points out.

The chapter on memory management under Java was a refreshing treat. Coming from a C++ background where resources are a major concern, I've heard many Java programmers use garbage collection in Java as a reason not to worry about resources. The book addressed how garbage collection worked in the past as well as current algorithms, and pointed out ways resources can be leaked quite easily. Awareness of a potential problem is one of the best tools a developer has, and the antipatterns addressed in this book will be ones I revisit when starting new projects. It's essentially defensive driving for developers, but fun to read!

Some sections concered areas I've only read about thus far, and it was interesting to see some problems in implementations based largely on following available "how to" guides. The list of suggested follow up reading will keep me busy for quite a while.

This is one of the few programming books on the market that is almost impossible to put down. Bruce Tate's ability to combine his passion for extreme sports with real life programming experience makes for a very interesting read. But don't think that means he puffed up this work with superfluous prose. This book is the real deal and packs more learning into it's 399 pages than most of the 800+ page technical tomes on the market.

The basic premise of the book is to define and describe anitpatterns. The author uses antipatterns as a force for good as wells as pointing out their inherent evil. Through the recognition and understanding of antipatterns the developer can learn the hows and whys of sound development process and program architecture.

Whether you are a seasoned developer or relatively new to programming, this book has something for you. The experienced developer will recognize many of the anitpatterns discussed in this book (though may not have known they had been named and categorized). The new developer will learn some very important concepts and situations to avoid.

Bruce's step-by-step refactoring of code will be a real eye-opener for a lot of folks in the Java community. This is some of the most straight forward architectural and procedure based instruction ever put to page. Yes, at times it may seem overly simplistic, but guess what?, that's what it's all about. The essence of good design lies in its simplicity. If you read through all of the examples, in the end you come out well on your way to becoming an architectural master (ok maybe overstated, but you will feel that way).

The book covers all the major components in an enterprise level application. You will get some for valuable tips on such things as MVC, cache management, connection pooling, and scalibility. Whether you are a web developer or a senior level enterprise programmer, there is something for you. This book should be required reading in every development shop and CS department!

Tate is trying to make a boring subject more fun.
You've seen that pattern before.

While not being the first one, he's definitely the first I've seen tying a story on bad Java design to another of him paddling a kayak.

He probably realized that, being a software consultant, putting out a lot of fires at his everyday clients, he needed to spice up the story with some real world downstream canoeing.

It turns out the Java examples are more interesting than the kayaking.

If you have touched any of these subjects:
# JSP

# EJB
# servlets
I'm sure you'll find Bitter Java's preaching interesting.

The books approach is to convert common anti patterns (a worst of breed approach to a problem) to good patterns.

He states many points, and the biggest is that even if you use Java/OOP/EJB/<insert buzz word here>, you'll still easily fall into the common traps of completely non-reusable code.
He doesn't just leave it there, but shows example on how to get out of it.

Bruce points out the most obvious facts about common mistakes, and you sit there nodding, but at the same realize you're doing just those mistakes.

One that JSP/ASP programmers will benefit from is the Model View Controller antipatterns.

On the EJB side he talks about facade objects. While you probably can read about those for free in Suns J2EE pattern Blueprints, it still nice to see real examples.

Some problems might be a little simple, and he enjoys the freedom that many programmers don't have: time to refactor existing code.

All in all, Bitter Java is a good read, using hands on examples with good solutions. I'd like to see Bitter java Advanced, where he'd tackle Java to database decoupling. Maybe I should write one myself.

/Thomas

If I had to summarize this book in a sentence, I'd say it's a conglomeration of good programming ideas mentioned in other books (Martin Fowler's "Refactoring" immediately comes to mind) targeted toward beginner to intermediate server-side Java programmers and framed in terms of what not to do.

That said, this book was a pleasure to read. This is one of the best-written technical books I've read. There has been an annoying trend over the past few years to include "humorous" footnotes every few pages...thankfully, this book has avoided that trend. While I'm sure some readers will be annoyed with the kayaking stories, I found myself looking forward to them. The author is a good storyteller and I read the book straight through.

One of the other reviews gives the impression that the author comes across as thinking himself smarter than the rest of us. I completely disagree.

To sum up, if you're relatively new to server-side Java programming and want to get started on the right foot, this book is a great choice. If you have several years of experience, you'll probably find yourself agreeing with the author a lot but not necessarily learning much.

Although some of the advice is valuable, the book should in no way be used as a direct source of clean code.

Pages 92, 113, 123, 132, etc. advocate using string building to create SQL queries. This technique is unreliable, in that it may create invalid SQL. It is also insecure, as it allows sending arbitrary expressions to the SQL server. It is also ineffecient, as it does not use the inline replacement syntax that most SQL servers allow for and can optimize.

Page 113 advocates using a numeric index based parsing methodology for handling the result set from an SQL query. This technique is weak and easily broken. Symbolic references, such as hash tables aligned with aliases in the SQL is a much stronger pattern that is much harder to break.

Page 113, 115, etc. advocate using strings for every type of data returned from the database. If the book advocates using a strongly typed language, why weaken it to a sub-Perl standard by using strings for all data types. I understand that this makes the JSP display code easier to write. If that is then intention then the model code is being weakened by the requirements of the view code.

Page 119 is using a for loop based indexing pattern over a returned results set. An enumeration pattern is best suited for this activity.

The section on caching presents a Perl based solution which is then replaced because the Perl did not cache. However, the author points out that the cache could have fit in memory. Most mainstream databases would have the database in memory and thus would only have the overhead of the network traffic, which in most cases is neglible. The author then proposes a solution with a singleton based cache which limits the entire deployment to a single web server (unless you want to put the singleton in another process, which gets you back to the neglible network overhead case.) A single server is much less scalable then multiple servers which use the database as cache. In short, this example throws the baby out with the bathwater.

Page 133 discusses the dynamics of a cache without introducing the notion of a forced cache flush. In complex caching systems a dependency mechanism for intelligent cache maintenance is a requirement. Certainly it merits at least a mention in this overview.

Page 137 makes reference to Listing 5.2, but no labelled listing 5.2 is to be found. Able readers will make the connection, but in general the listings should be numbered if they are to be refered to by number.

The vast majority of programming books focus on a particular topic, API, or technology; few books try (and fewer succeed) to teach the reader something about the art and science of programming itself.

In Bitter Java, Bruce Tate has collected and catalogued a number of common programming mistakes that he's seen show up over and over again in server-side Java development (these ubiquitous errors are sometimes called "antipatterns"). Each entry includes an explanation of why these traps are so easy to fall into, and describes the basic programming practices each antipattern violates.

The approach of showing how things are commonly done incorrectly, rather than just saying "Here's how to do it right", works quite well. Mistakes are a better teacher than success.

In reading Bitter Java, experienced programmers will nod in familiarity, and less experienced programmers should be able to easily grasp the essence of what is wrong with the examples being presented.

The antipatterns explored in Bitter Java cover a broad range of applications and situations, and Tate supplements the pattern catalog with relevant anecdotes and descriptions of the projects in which they occurred, making the text much more engaging than a simple pattern catalog would be.

A fast and enjoyable read, and has something to offer all but the most experience developer.

I have long wondered why so many books existed that were API reference books. Such books must sell well because for every new version of an API there are a number of new books that rehash what is freely available on-line. Such books generally offer no thought provoking material and do little to help me solve real world problems. Tate's 'Bitter Java' is NOT one of those books.

Tate offers a very insightful and unique way of helping readers to better understand what factors need to be taken into consideration and how to answer real world problems. By looking at 'normal' code, the author makes it clear as to what developers are trying to accomplish and why they did what they did and what the pitfalls are in how they did it. He then takes a page right out of extreme programming and refactors, refactors, refactors until the code is optimized. Each step of the refactoring process is explained in enough detail to understand what the problems were in the original code and what the benefits are in the refactored code.

The examples, which the author uses, are consistent across the entire book, which at times makes reading it seem somewhat redundant, but is what makes the examples so understandable. Time does not need to be spent restating what the code is trying to accomplish. The examples are also very prudent. It is very easy to picture the examples as being code that was taken out of a system that you are working on.

This book lies somewhere between a patterns book and a java implementation book. At a high level, what Tate advocates in each chapter is the use of a pattern, but he does not attempt to cover a large set of patterns. Instead, he has chosen to look at a variety of common bad practices and advises certain patterns be used to correct them. This book goes into a lot more hands on implementation of patterns than an ordinary pattern book. It is much more suited for hands on development use than the academic nature of most books. This non-academic focus of the book is what makes it so useful.

I really enjoy getting people's insight into real world experiences and am often frustrated that I cannot get more people's insight. I would much rather learn from someone else's mistake than my own. This is why I like this book so much. It allows me to build upon the knowledge and experiences of my peers.