Bitter Java and Patterns

[Doug Wang]

Hi all,
This weeks giveaway sounds interesting. It seems like another AntiPatterns book. I wonder how Bitter Java teachs us to apply patterns or antipatterns.
Lets enjoy the bitterness of Java.

[Wilfried LAURENT]

Looking at the index, it seems that it is very "server" orientated.
Can anybody tell me if it is interesting for someone working daily with Java but not in the "server-side" context?
W.

[lusha tak]

I am a software developer, working on java related technology...the title of the book sounds very intersting..i feel this book can help me in someway
so here am i participating for the drawing

[Junilu Lacar]

Doh! I didn't realize it was "carpetbagger week"
Oh well, Welcome everybody! (I think)
Junilu

[Junilu Lacar]

Can anybody tell me if it is interesting for someone working daily with Java but not in the "server-side" context?

As far as I can tell from the table of contents, it is largely about anti-patterns on the server side.
This book is currently being reviewed by one of the moderators (unfortunately, not me) so there should be a review on it in the Bunkhouse soon.
Junilu
[ June 04, 2002: Message edited by: Junilu Lacar ]

[Junilu Lacar]

Actually, the review of the book has already been posted: http://www.javaranch.com/bunkhouse/bunkhouseAdvanced.jsp

[Michael Yuan]

Speaking about book reviews. I reviewed it here:
http://pancake.as.utexas.edu/juntao/book_review/bitterjava.html
enjoy

[Varun Narula]

Hi All,
A very interesting name for a book !!
But i guess that's quite appropriate for a technology that is maturing.
When a technology is new one normally sees a spate of 'How To' Books and then when it is nearing the maturity level, one should be seeing 'How not to' and 'Why Not To' - Bitter just sounds kinda cute ... Coffee is bitter anyway
Varun Narula
SCJP

[Joshua White]

<quote>
"carpetbagger week"
</quote>
Thats great stuff!

[Doug Wang]

I like the way this book explains Anti-patterns with example code. Putting the original and refactered code together gives you deeper impression on different mistakes.
Thanks Michael for your contribution.

[Bruce Tate]

Thanks for all of the questions and comments. Here's a little bit about Bitter Java, and the answers to some of the questions.
Bitter Java does introduce antipatterns to the Java community, but at a much lower level than the AntiPatterns book. (Skip McCormick, co-author of AntiPatterns, actually wrote the forward.) I try to wrap three high level concepts together: antipatterns, design patterns and refactoring. Philosophically, I try to make the case that design patterns and antipatterns are necessary and complimentary. I believe that we learn in three stages. The first is to nail down the basic API. The second is to gather experience. The third is to apply patterns. I beleive that one of the most important learning elements in the life of a programmer is failure. Bitter Java attempts to shorten that process by providing a list of common mistakes. Especially if you're an intermediate programmer, or a mentor, you can learn or teach the fastest by identifying and generalizing designs, both good and bad.
Now to some questions.
1) Is Bitter Java just for server side programmers? Bitter Java is mostly about server side techniques (in fact, the banner on the book says lessons from server side Java antipatterns), but contains many principles for the every day Java programmer. A few of the interesting topics are memory management, performance tuning, good topologies and programming hygiene.
2) Is Bitter Java about antipatterns? Yes, but I put them in a context that's most useful for rapid Java development. Specifically, I also introduce the combination of antipatterns (the beginning), design patterns (the end), and refactoring (the road). I also spend more time at lower levels than AntiPatterns.
3) Is Bitter Java advanced? No. I target the intermediate programmer first. I wanted to start with some pretty sound footing to introduce the overall concept. I'm working on some followons that will be more advanced. If you're an advanced programmer, you'll probably find something, but clearly not as much.
4) What has made Bitter Java so successful? I really don't know. When we cracked the Amazon top 10 (!), no one had ever seen this combination before: a small time publisher, a relatively unknown author, a down Internet economy, and a programming book and the ultra-high ranking. I do believe that the book is funner to read than most. Manning did an exceptional job editing the book, and the extreme sports stories came across very well, making the book fun to read cover to cover. I think that the Internet bust also comes into play. We want to know where our technologies let us down, and not just economically.
I'll be around today and tomorrow to answer questions. Thanks for all of the interest in the book. It's been fun so far.

[Junilu Lacar]

Thanks Bruce. And Welcome to JavaRanch!
Sounds pretty good. I have the AntiPatterns book and found it a very good read. One thing they talk about in that book is how some AntiPatterns are really good patterns used in the wrong way. From the table of contents, I see that you may have some examples of this such as the mini-Antipatterns for EJBs.
Looking forward to reading this book soon...
Junilu

[Corey McGlone]

I have gathered that this book talks about real-life projects that failed and why they failed. Is this true? If so, what types of projects are we talking about?
Thanks,
Corey

[Bruce Tate]

I have gathered that this book talks about real-life projects that failed and why they failed. Is this true? If so, what types of projects are we talking about?

Corey, Bitter Java is a collection of antipatterns collected from a series of consulting engagements from various sources. I worked as the team lead for a national Java proof-of-concept team at IBM for two years. It was primarily a consulting position, and we frequently worked to bail customers out of struggling projects. Later, I led the solutions development organization for an Austin startup.
I mention a few of the projects in Bitter Java explicitly, but most are collections of antipatterns, meaning that they occured in many different places (3 or more). Most of the accounts were traditional fortune 100 companies, like big banks, insurance, transportation, state and fedeeral government and even a little manufacturing. For the most part, I worked with teams that had very little Java experience. Our focus was primarily on integration of legacy database and transactional applications, though we also did some messaging.
I realize that this is a general answer to a specific question, but that's the way that Bitter Java is written. I tried to point out the most common and/or destructive server side Java antipatterns. For example, the Magic Servlet problem occurs nearly everywhere. I've seen it at one of the top 3 insurance companies, two of the top 5 US banks, a top international airline, and many other places.

[Junilu Lacar]

Originally posted by Bruce Tate:

For example, the Magic Servlet problem occurs nearly everywhere.
Interesting name. Would you care to elaborate on it a little for us?
Junilu

[Gerry Giese]

Sounds like a great book! I need to go look up the TOC, but in the meantime, how much of the 'server-side' time is spent on various topics, such as JSPs, servlets, EJBs, MVC frameworks (struts, velocity and the likes), RMI, SOAP/Web Services?
One issue that has plagued me all year is people insisting that EJBs solve world hunger. In my situation we have one server and it's unlikely that we would get more except possibly to cluster it. Also, we don't have a clear need for heavy-duty transactions. So why go through the headache and performance loss in using EJBs is what I say. Sounds like the new EJB spec is better about local EJB connections, though, so it does appear to be getting better...
BTW, Bruce, congrats on the great sales! If I don't win a copy I'll probably buy one. Cheers!

[Corey McGlone]

Originally posted by Junilu Lacar:
Originally posted by Bruce Tate:

For example, the Magic Servlet problem occurs nearly everywhere.
Interesting name. Would you care to elaborate on it a little for us?
Junilu

Funny, that's just what I was going to ask. What is the magic servlet problem?
What I was really asking was how detailed is the book. Does it show examples of how people used patterns incorrectly, or does it just discuss the way patterns/antiatterns should or should not be used.
From what I've gathered, it would seem as if there are plenty of concrete examples of misused patterns.
Corey

[Leslie Chaim]

Sounds very interesting,
From a Java and OO prospective, I thought everything MUST have a pattern. I mean just the "hello world" program has to be in a class. For an extreme example, see the world's-most-complicated-way-to-print-hello-world in "Taming Java Threads" by Allen Holub page 150. Again, you have patterns there specifically with the 'publish/subscribe' pattern.
Being from the self-thought school, I have a general weakness when it comes to books and I like to get all of themJ
I am trying my luck though, and just like Gerry Giese if I don't win I probably will not resist the temptationJ
Looking forward to it.

[Junilu Lacar]

Originally posted by Leslie Chaim:
Sounds very interesting,
I thought everything MUST have a pattern. I mean just the "hello world" program has to be in a class.
I think I see where you're coming from. However, when we talk about code I believe these "patterns" are more commonly referred to as "programming idioms".
I think of patterns as more generic and at a higher level of abstraction, capturing the "essence" of the solution rather than the concrete solution itself. Although you'll often see code examples in discussions of patterns, you shouldn't think that there is just one solution. The power of patterns lies in their generality: there can be a number of different solutions that follow the same pattern.
My $0.02
Junilu

[Corey McGlone]

Going along with Junilu, this is how I think of patterns:
Let's say I'm building an application which will have multiple windows displaying the same data, just in different formats. When you update the data from one screen, you'll want the others to change appropriately to reflect those changes.
When I develop a system like this, I note that I could probably use an Observer pattern to achieve the desired result. Often, I try to identify applicable patterns even before I get far into system design.
Corey
[ June 04, 2002: Message edited by: Corey McGlone ]

[Frank Zheng]

Hi Bruce,
Welcome to JavaRancher.
Could you give us a short example to demonstrate how to make trade off between patterns and non-patterns. Just like the economic patterns, one country's pattern may be totally harmful to another country. We should not apply patterns blindly, right? But, how could we tell? This seems close related to how much experiences the developers have.
How do you address these trade off making in your book?
Thanks a lot!

[Junilu Lacar]

Originally posted by Frank Zheng:
We should not apply patterns blindly, right? But, how could we tell? This seems close related to how much experiences the developers have.

This is a good question and I would just like to put in my two cents.
As I mentioned sometime today (it's been so hectic around here lately :roll: I'm having a hard time keeping track of the threads), a perfectly good pattern can become an antipattern when applied incorrectly. There are even those in the development community who recommend not focusing on patterns themselves: just do refactoring deligently and oftentimes you will find that you have actually refactored yourself into a pattern!
See also http://www.industriallogic.com/xp/refactoring/
Bruce, what is your experience and do you touch on this in your book?
Junilu
[ June 04, 2002: Message edited by: Junilu Lacar ]

[John Sinues]

Based on the preliminary reviews, Bitter Java, sounds like a good book to have in one's server library. It looks like it is geared more towards J2EE although some of the concepts introduced could be applied to Java in general. It'll be a nice book to "win" for my library.

[Bruce Tate]

Thanks for the continued comments.
The Magic Servlet is an antipattern that occurs when you try to put all of the server side logic for a single task into one very large servlet. For all of you SmallTalk or Model-View-Controller freaks, that means that the same servlet is doing three major tasks:
1) It serves as an entry point for the task, and marshalls the data between the original HTML (the one that called the servlet in the first place, the upstream view), the "business logic" (the model), and the response view (the downstream view).
2) It processes any server side programming logic. This might include database code, the firing of transactions, and messaging. This is the "model", or the client/server "service".
3) It prints the resulting HTML page, or the downstream view.
The Magic Servlet is common for many client-server programmers, because they're used to handling all of the view logic in the client and the model logic at the server. The client-server infrastructure usually serves as the controller. The problem is that with the servlet model, there are two views: the request and the response. To effectively organize your code, you've got to break out the model (bean), downstream view (JSP) and controller (servlet) separately.
A form of this "antipattern" occurs with regularity with frameworks like VisualBasic, because many simply build the user interface and hang all of the code off of a single "ok" push button. The tool's organization and early documentation encourage the design. It didn't happen as much with Java until we started using servlets. I'll answer some of the other questions in another thread.

[Bruce Tate]

One issue that has plagued me all year is people insisting that EJBs solve world hunger.

Totally agree. That's one of the antipatterns in the book. I only spend one chapter for EJB for that reason. I do plan to write a book specifically for EJB antipatterns, and plan to open it with a chapter on when and why you'd apply EJB.

[Bruce Tate]

What I was really asking was how detailed is the book. Does it show examples of how people used patterns incorrectly, or does it just discuss the way patterns/antiatterns should or should not be used.

I'm not sure that I completely understand, but let me take another shot. Bitter Java captures common traps, and explains how to turn these "negative patterns", or antipatterns, into solid solutions, which may be design patterns.
Some of these antipatterns are indeed misapplied design patterns, like the "Round Bean in s Square Hole" which is simply a case of using the wrong kind of EJB for a problem. Others are sins of omission, like the "Cacheless Cow". In this case, developers simply neglect to take advantage of the benefits of caching, and take a severe performance hit as a result. Some involve a total lack of any design at all, like the "Magic Servlet".
As to the level of detail, in most cases, I present code for the problem and the solution.

[Junilu Lacar]

Originally posted by Bruce Tate:
Thanks for the continued comments.
All well-deserved. And hoping that flattery will get them something...
The Magic Servlet is an antipattern that occurs when you try to put all of the server side logic for a single task into one very large servlet.
IOW, it's the Server-Side Blob/Big Ball of Mud/ Garbage Barge.
Junilu

[Bruce Tate]

Could you give us a short example to demonstrate how to make trade off between patterns and non-patterns. Just like the economic patterns, one country's pattern may be totally harmful to another country. We should not apply patterns blindly, right? But, how could we tell? This seems close related to how much experiences the developers have.

Good question, that's really a combination of a few different issues. Can we first agree that patterns are common solutions to problems? Design patterns have observable benefits and antipatterns have a negative impact.
The hard part of this question is this:
1) How do you tell if you're applying a design pattern correctly? I think that the answer to this one is experience and study.
2) How do you tell if a given pattern is a good one? First, I think that you get your patterns form reputable sources, where at all possible. Second, I think that you watch the way that consumers use your code. Many times, the consumers are the programmers around you. If they frequently misuse your code, you need to look into what's causing that negative behavior. Often, patterns appear to be more complex than you think that they should. The benefits don't become clear until others extend the base patterns. Those are the toughest to apply, unless you study patterns.
I think that the contribution of Bitter Java into this equation is that there *are* both positive and negative patterns out there, and you've got to be able to recognize each one.
Just my two cents.

[Bruce Tate]

I enjoyed these, especially Garbage Barge:

IOW, it's the Server-Side Blob/Big Ball of Mud/ Garbage Barge.

You can literally find 100s of names for the Magic Servlet. This is the one that I chose for the book, because of the roots back to the earlier Visual Basic designs. When I present, many know this antipattern as "Bruce's Magic Pushbutton." I must spend way too much time on my soap box.

[Corey McGlone]

Well, now that you explained it, of course I've seen the magic servlet antipattern. I had just never heard it called that before. Of course, I never heard any of the wonderfully colorful terms Junilu used, either, but I like 'em.

As to the level of detail, in most cases, I present code for the problem and the solution.

That was what I was wondering.
Thanks,
Corey
[ June 04, 2002: Message edited by: Corey McGlone ]

[Ilja Preuss]

Originally posted by Junilu Lacar:
There are even those in the development community who recommend not focusing on patterns themselves: just do refactoring deligently and oftentimes you will find that you have actually refactored yourself into a pattern!

Notice though that most of them nevertheless value the knowledge of design patterns very much. It is just knowledge to be applied with alertness.
That is, while refactoring you might notice that the code wants to be refactored to a specific pattern. But later you might notice that the code wants the refactoring to stop even before the pattern fully materialized, or it wants it to be slightly adjusted etc.

[Junilu Lacar]

Originally posted by Ilja Preuss:

Notice though that most of them nevertheless value the knowledge of design patterns very much. It is just knowledge to be applied with alertness.

Yes... I've always wondered though, does knowledge of patterns somehow subliminally influence the refactoring into them or does it just follow that improving the code to conform with good design principles naturally gravitates the design toward certain patterns, even without the designer being aware of the patterns. Patterns are discovered, not invented. But I guess so were good design principles. So which comes first, patterns or good design principles? Chicken or egg?
I guess it's kind of hard to tell since most good designers are aware of both good design principles and design patterns... Oh well.
Junilu

[Corey McGlone]

You're right, Junilu, this is the chicked or the egg question. :roll:
However, my presumption is that, originally, developers discovered which design pronciples worked well and utilized those principles and probably noted that, often, to sove similar problems, they came up with similar designs. These designs would come to be known as "patterns."
So, in the beginning, I would have to presume that solid design principles precluded patterns. Of course, with that, I believe that developers were using patterns even before they knew they were patterns. After all, was the first singleton really called a singleton? :roll:
I suppose I could argue around myself in circles all day...I think I'll go hang out in the SCJP forum where everything has a clear-cut answer.
Corey

[Bruce Tate]

I think that one of the neat things about Bitter Java is the combination of antipatterns, design patterns, and refactoring. They all go together. It's all about recognition: you want to recognize certain problems and solutions that work, and you also want to recognize and avoid or refactor those things that don't.
That knowledge, your situational mental encyclopedia of patterns, more than anything else, separates good programmers from great ones. More than a working dictionary of designs, the value of patterns and antipatterns is the expression and communication of designs that work and those that don't.

[Junilu Lacar]

Originally posted by Bruce Tate:
I think that one of the neat things about Bitter Java is the combination of antipatterns, design patterns, and refactoring. They all go together.
And maybe that's the "X factor" that's been working for this book. You've probably covered the different aspects well enough to make everything come together in the minds of readers so that it all "clicks". I definitely want a copy of this for Father's Day
Junilu

[Frank Zheng]

Bruce: That knowledge, your situational mental encyclopedia of patterns, more than anything else, separates good programmers from great ones.

Good Point!!!
Good design of software is an art more than a science.

[Frank Zheng]

Have you guys met this situation:
Even though everybody are aware of the principles of good design and patterns, it is not necessary that these principles be applied in real-world programming. Historical reasons, resources, political barrier are all possible obstacles that prevent good programming rules being carried out. Is this a hard topic in project management?

[Junilu Lacar]

Originally posted by Frank Zheng:
Have you guys met this situation: ...
:roll: Of course. Why do you think "Dilbert" is so popular?

[Frank Zheng]

I know why Bruce wrote a "Bitter" book now.

[Corey McGlone]

Even when everyone (including management, which is a rarity) knows what the "right thing to do" is, sometimes that just doesn't get done because of time constraints, excessive cost, etc. Unfortunately, all too often, the wrong thing is done because it's cheaper.
Corey