Bitter Java

Peter Wayner writes: "There are 1693 books for sale at Amazon.com with the word "java" in the title and almost all of them are earnest, chipper books that promise real programmers, dummies , and nuts that learning Java is easy. Bruce Tate's, Bitter Java , is not one these books." Read on to see if you'd like to experience Bruce Tate's bitterness first hand.

Bitter Java: The lessons taught by server-side Java Antipatterns
author	Bruce A. Tate (with help from Braden R. Flowers)
pages
publisher	Manning
rating	8
reviewer	Peter Wayner
ISBN	1-930110-43-X
summary	A collection of bad habits to avoid for server developers using Java.

Writing and reading technical books is both a pleasure and a chore. Programming computers can be great fun, but doing the job well requires almost impossible amounts of discipline, attention to detail, and pure drive. The machines churn through billions of operations per second and a mistake in just one can send everything tumbling out of control. Most authors tend to gloss over the difficulty by tossing in a spoonful of Mary Poppins because it does little good to grouse. It's just so simple and straight-forward to toss in optimistic words like "simple" and "straight-forward."

Tate's approach is looks a bit different. He wants to follow in the tradition of Frederick Brook's Mythical Man Month and talk about software development with an honest voice. Microsoft executives, Objective C devotees, and assembler lovers will be disappointed because the title is a bit misleading. He's not really bitter about Java in the way that Princess Diana was bitter about the British Royalty, he's just had a few bad experiences and he wants to help us learn from them.

In fact, he's not even writing about Java in the general sense. The book concentrates on the problems that often arise with most popular and complicated applications for the technology like servlets and enterprise Java beans. If you're building a web site based on Java, then you might want to read through this book.

The structure itself is devoted to uncovering antipatterns , a term Tate uses because it plays off the way that Sun offered Java patterns to help programmers use the new tools efficiently. Most of the chapters show the wrong way to build something and then show how to correct it.

Chapter 8, for instance, demonstrates a bulletin board that seems to be well-designed on the surface. The parts of the data structure are broken up into suitable objects and every object comes with a collection of methods that act as gatekeepers for the data inside the object. It all looks elegant, but it performs badly especially on large installations when the objects live on different servers. Suddenly, all of the extra well-meaning object-oriented engineering starts jamming the flow. Wrapping every object with so much glue code is like hiring more workers to speed up a bureaucracy. Tate shows how to aggregate the calls and speed things up dramatically by cutting through the misapplied object-oriented concepts.

If you step back a bit and think about the book from a distance, the right title starts to look like "Bitter Object-Oriented Programming". Most of the problems in the book emerge when seemingly good uses of OOP turn out to be terribly slow when implemented. While all of the problems are practical hurdles awaiting Java programmers, they must have cousins in the world of C++ and the other OOP languages. Splitting things up into many objects is plenty of fun at the beginning, but when the messages start flowing, the code becomes a swamp.

After a few chapters it becomes clear that object-oriented programming is starting to reach practical limits. The theory may be elegant, but programmers can only make it work if they use guidebooks like Tate's. The object-oriented toolkits are too easy to use dangerously. So what is the solution?

This kind of guidebook filled with antipatterns may be the best we can do for now. Tate himself says that the book is filled with "merc talk", the kind of chatter about hair raising experiences he says that mercenaries trade when they're sitting around the fire. This is an apt description. If you're a hired codeslinger creating J2EE applications or servlets, then this is a good book for your shelf.

---

Peter Wayner's latest two books are Translucent Databases , an exploration of how to create ultra-secure databases, and Disappearing Cryptography: Information Hiding, Steganography and Watermarking , a book about mathematical parlour tricks, sleights-of-hand, and subversive things you can do with bits. You can purchase Bitter Java at bn.com, and you can join Peter in reviewing books by submitting reviews after reading the book review guidelines.

Examples, please!

[Shimmer]

Before we get out the brickbats, can someone please post an example of the horrors of OO technique that are referred to here.

As someone who has used OO successfully for 10+ years, I'll have a hard time accepting these OO "antipatterns" without concrete examples.

-- Brian

Re:Development Processes be damned..

[Anonymous Coward]

design patterns does not a cookie cutter make..

The only programmers using design patterns are C++ and Java programmers. Do you know why? Because the "patterns" are meant to overcome language hurdles that dont occur in lisp and strictly functional languages.

How many language designers besides Stroustrop constantly defend their language on usenet by appealing to C's popularity? He's a brilliant guy, but that argument is a crock.

anti-antipatterns

[graveyhead]

If design patterns are used correctly, they accomplish one of 2 things, but rarely both:

they speed up the development of a system
or

they speed up the execution of a system

This is, of course, one of the fundamental trade-offs that us computer programmers make all the time. The important part is choosing a pattern that is appropriate for the system. For example, the flyweight pattern is used to limit/reuse objects in a system. It is appropriate to use this pattern when top execution speed is necessary, but the price is the complexity of implementation.

The facade pattern, OTOH, is designed to make life simpler for programmers, potentially at the cost of execution speed.

It sounds to me like this guy has trouble picking the appropriate patterns from the start.

Re:My Gripes about Java &tm;

[Anonymous Coward]

Mmm, trolling. This is the second time I've seen this exact post.

I suppose that this provides an interesting commentary on karma: I've seen a fair bit of people posting the exact same post as many times as possible to try to maximize karma with minimal effort.

- Coffee (using a cow orker's terminal)

In other words - programming is hard!

[putaro]

So, if you write a system that runs across multiple servers you can end up with a poorly performing system if you don't know how to separate functionality out properly. From the Unix Hater's Handbook:

If C gives you enough rope to hang yourself, then C++ gives you enough rope to bind and gag your neighborhood, rig the sails on a small ship, and still have enough rope to hang yourself from the yardarm.

I would say that Java shortens the rope but then lets you hook it up to a power winch. Modern toolkits and languages are really powerful. Being able to write a distributed application so easily that YOU DIDN'T NOTICE HOW DAMN MANY CROSS SERVER CALLS YOU WERE MAKING is pretty amazing. On the last large project I did we used Java and I noted that Java made locking so easy that we swept right past the easy locking problems (like, did you remember to release the lock) and straight into the really nasty ones. I think that going beyond "Learn Java in 21 Days" into how to break your functionality out properly is a wonderful topic for a book but the gratuitous swipe a Java doesn't seem useful. Just remember, "Power tools for power fools."

Thinking in Java

[garoush]

The best Java book that I have seen so far is "Thinking in Java" by Bruce Eckel. Here is why.

While Mr. Eckel's book does covers the syntax of the language (java in this case) et. al, it also cover the meaning of the language and most of all, it covers how to think in the language (hence: the title).

Almost any developer can pickup a language and become knowledgeable with it by working on one or two projects. However, being *proficient* at your domain, and understanding coding-principles of the language for your domain, and understanding the business of being a programmer is much more difficult goal to achieve -- only time, experience, and dedication will ever get you there. It is this quality that I look for first, the knowledge of a language comes third.

Here is a link that I point people at to high-light my point: Chicken Soup for Your Modeling Soul [sdmagazine.com] -- I specially like item 21: "A fool with a tool is still a fool".

Thanks for the kind words.

[BitterJava]

I'm truly not worthy. You have elegantly and accurately captured the spirit of Bitter Java. I spent a whole lot of time as a Java architect and consultant, and noticed a whole lot of repeated mistakes. Bitter Java is about capturing those mistakes and wrapping them up, so that others can avoid them. I've got a weakness for kayaking, and that comes through (a little too strongly?) in the book. One of my favorite pictures is of a friend leaning against a sign after driving all night, and yawning. We snapped the shot, and then pointed out the words on the sign: "Seven people have drowned here." Of course, after wetting his pants, Eric was about to get in his kayak and run the falls. That's a perfect antipattern. Literary form; concise; points out a negative behavior (playing under the falls), and the decidedly negative consequence. That's Bitter Java. Of course, you've also got to point out how to avoid the negative consequence, and thus the emphasis on refactoring in Bitter Java. I definitely cannot claim credit for creating antipatterns. (Thanks to the reviewer who compared me to Al Gore...priceless.) In fact, one of the authors of the best-selling Antipatterns book, Skip McCormick III, wrote a glowing forward for Bitter Java. Thanks, Skip.

Re:This book is right on the money

[BitterJava]

Hmmm...I'll have to reread my last chapter. That explains the amazon spike. Microsoft junkies are eating it up... ;)

Sounds like DB normalization??

[geolane]

This review sounds exactly like database normalization- one does not end up with twenty tables each with two columns and expect wonderful performance- sometimes that repeated data that might (in a fully normalized database) speed performance by a significant amount. Joins in the database world cost cycles- I think the same thing holds in the OO world- don't normalize to the nth degree.

CLOS *isn't* OO?

[alispguru]

I suspect you and I have different definitions of OO. The problem is that damn near everyone has a slightly different definition of OO. Go read this article [paulgraham.com] by Johathan Rees, then come back and tell us what you mean by a "real OO system", and why you can't do it properly in CLOS.

Modern C++ Design

[Anonymous Coward]

Everyone involved in the C++ vs. X debates should read this book. It shows quite clearly everything that is good and evil about C++. The fact that there aren't ANY compilers which can actually run all the examples in that book is pretty telling in itself.

Lisp is great. Where is Lisp?

[Anonymous Coward]

Lisp is great - it is very flexible. But the problem of Lisp is in its flexibility: it's too flexible. As a result, there are lots of Lisp dialects. They are compatible by skills, but it is difficult to create portable Lisp applications. There is no portability - there is no popularity in OSS community.

Most of Lispers are coding with commercial implementations, while there are very few of great Lisp applications based on free/OSS implementations. Emacs is the best of them, but it is dying. TeXmacs is upcoming, but will it succeed So, there are lots of Lisp dialects, but it is even worse - most of (good) imlementations are commercial.

Today we are living in the time of XML. But most of popular XML applications are written on Java, Python and even Perl - but not on Lisp. Why? Theoretically Lisp is the best candidate for XML processing/transformation, why not to use it? I'll tell you why - because there is no such thing as Lisp - instead, there are too many of Lisp dialects. Thus, for most of programmers it is uncertain, which Lisp to use. And that's why programmers prefer to use Java, C, Python or Perl.

Now see what you are saying about Lisp patterns. It is less important which pattern to use when you don't know which dialect to use. Give Lisp to masses and you will be surprised how many patterns people will use with Lisp. Academical thinking dislike patterns, practical thinking cannot live without patterns.

Patterns don't just go away

[tarmo]

Hey, design patterns are just generally applicable ways of designing things (like software) that usually (through prior experiences) produce good designs that are robust, flexible, or whatever is wanted.

Everything that has to do with designing and is (relatively) commonly used and works is a design pattern.

Procedures are a pattern, just like OO. But when your implementation environment directly supports that pattern, then it becomes just a mundane tool.

Many GoF patterns are for C++ and Smalltalk, because those were the languages that the GoF had experience in. The patterns were meant to produce better designs for those languages. Because the implementation isn't supported by the language, a specific pattern must be enforced on the programmer.

Lisp doesn't need most of the GoF patterns due to its superior features, but that doesn't mean the patterns aren't there - they're just easier to implement. But if you don't use them, then your design won't be any better just due to your selection of language. And using a language or an environment that provides these basic patterns for you allows you to concentrate on even higher level patterns.

Or have you seen anyone implementing class inheritance using assembly? I haven't. It's a bit easier when the language handles stuff like named variables, scopes, functions and type checking, just to name a few very commonly used design and implementation patterns that help implementing an OO system.

--
Tarmo