Bitter Java 427
| 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.
All I want to know is.. (Score:2, Funny)
Sun invented patterns? (Score:3, Funny)
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.
And Al Gore invented the internet. Or was that Bill G again?
My Gripes about Java &tm; (Score:5, Funny)
I'm a first year programming student at a local community college school and I've just finished my Visual Basic classes. This term I'll be moving onto Java. However I've noticed some issues with Java that I'd like to discuss with the rest of the programming community. Please do not think of me as being technically ignorant. In addition to VB, I am very skilled at HTML programming, one of the most challenging languages out there!
Java is based on a concept known as Object Oriented Programming. In this style of programming (also known as OOPS in the coding community) a programmer builds "objects" or "glasses" out of his code, and then manipulates these "glasses". Since I'm assuming that you, dear reader, are as skilled at programming as I am, I'll skip further explanation of these "glasses".
Please allow me to make a brief aside here and discuss the origins Java for a moment. My research shows that this language is one of the oldest languages in existance, pre-dating even assembly! It was created in the early 70s when AT&T began looking for a new language to write BSD, its Unix Operation System (later on, other companies would "borrow" the BSD source code to build both Solaris and Linux!)
Back to the topic on hand, I feel that Java - despite its flaws - has been a very valuable tool to the world of computers. Unfortunately its starting to show its age, and I feel that it should be retired as C++, Python and Perl seem to have been. Recently I've become aquainted with another language that's quite recently been developed. Its one that promises to greatly simplify programming. This new language is called COBOL.
Although syntactically borrowing a great deal from its predecessor Ruby, C greatly simplifies things (thus its name, which hints at its simpler nature by striping off the klunky double-pluses.) Its biggest strength is that it abandons an OOPS-style of programming. No more awkward "objects" or "glasses". Instead C uses what are called structs. Vaguely similiar to a Java "glass", a struct does away with anachonisms like inheiritance, namespaces and the whole private/public/protected/friend access issues of its variables and routines. By freeing the programmer from the requirement to juggle all these issues, the coder can focus on implementing his algorithm and rapidly developing his application.
While C lacks the speed and robustness of Java, I think these are petty issues. Given the speed of modern computers, the relative sluggishness of C shouldn't be an issue. Robustness and stability will occur as C becomes more pervasive amongst the programming community and it becomes more fine-tuned. Eventually C should have stablity rivalling that of Java.
I'm hoping to see C adopted as the de facto standard of programming. Based on what I've learned of this language, the future seems very bright indeed for C! Eventually, many years from now, perhaps we'll even see an operating system coded in this langauage.
Thank you for your time. Your feedback is greatly appreciated.
Here's a book title... (Score:2, Funny)
Re:Here's a book title... (Score:2, Funny)
intersting book title, but it would get called POOP for short
Edited for the "for dummies" series: (Score:3, Funny)
Chapter 1
The joys of 0
Chapter 2
The joys of 1
Chapter 3
0 meets 1
there was an island between Sumatra and Bali... (Score:4, Funny)
Danny (who plays gamelan [danny.oz.au] and is interested in Indonesia [dannyreviews.com]).
Re:My Gripes about Java &tm; (Score:2, Funny)
Re:All I want to know is.. (Score:2, Funny)
Re:Examples, please! (Score:3, Funny)
Re:Development Processes be damned.. (Score:4, Funny)
For some functional languages, it seems you can use any design pattern you want - as long as it's recursion.
Re:Development Processes be damned.. (Score:3, Funny)
Undoing that divison??? What about:
Employee
|
--------------
| . . . . _ . . . . |
Manager . . . . Slave
No need to undo anything. Processes that don't care about the division code to Employee's.
Plus, the managerial status may be temporary, fleating, or vague.
Associations may be better for temporary, fleeting or vague manager relationships (perhaps using a Project-class?). I really don't see why those relationships can't be properly managed in OO code.