This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Bitter Java and Patterns Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Bitter Java and Patterns" Watch "Bitter Java and Patterns" New topic
Author

Bitter Java and Patterns

Doug Wang
Ranch Hand

Joined: Oct 05, 2001
Posts: 445
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.


Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep
Wilfried LAURENT
Ranch Hand

Joined: Jul 13, 2001
Posts: 269
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
Ranch Hand

Joined: Dec 30, 2000
Posts: 185
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
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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

Joined: Feb 26, 2001
Posts: 4456
    
    6

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
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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

Joined: Mar 07, 2002
Posts: 1427
Speaking about book reviews. I reviewed it here:
http://pancake.as.utexas.edu/juntao/book_review/bitterjava.html
enjoy


Seam Framework: http://www.amazon.com/exec/obidos/ASIN/0137129394/mobileenterpr-20/
Ringful: http://www.ringful.com/
Varun Narula
Ranch Hand

Joined: Nov 19, 2001
Posts: 90
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


There are only 10 types of people in this world; those who understand binary and those who dont<p>Varun Narula <br />SCJP, SCWCD, IBM-486 (UML)
Joshua White
Ranch Hand

Joined: Jun 04, 2001
Posts: 97
<quote>
"carpetbagger week"
</quote>
Thats great stuff!
Doug Wang
Ranch Hand

Joined: Oct 05, 2001
Posts: 445
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
Author
Ranch Hand

Joined: Jun 04, 2002
Posts: 71
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.


First rule of Kayak: When in doubt, paddle like Hell
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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


SCJP Tipline, etc.
Bruce Tate
Author
Ranch Hand

Joined: Jun 04, 2002
Posts: 71

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
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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
Ranch Hand

Joined: Aug 02, 2001
Posts: 247
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!


CJP (Certifiable Java Programmer), AMSE (Anti-Microsoft Software Engineer)
Author of Posts in the Saloon
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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
Ranch Hand

Joined: May 22, 2002
Posts: 336
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.


Normal is in the eye of the beholder
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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
Ranch Hand

Joined: Jun 12, 2001
Posts: 76
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!


Sun Certified Java Programmer
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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
Ranch Hand

Joined: Feb 21, 2000
Posts: 52
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
Author
Ranch Hand

Joined: Jun 04, 2002
Posts: 71
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
Author
Ranch Hand

Joined: Jun 04, 2002
Posts: 71

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
Author
Ranch Hand

Joined: Jun 04, 2002
Posts: 71

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
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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
Author
Ranch Hand

Joined: Jun 04, 2002
Posts: 71

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
Author
Ranch Hand

Joined: Jun 04, 2002
Posts: 71
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
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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
Author
Ranch Hand

Joined: Jun 04, 2002
Posts: 71
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
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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
Ranch Hand

Joined: Jun 12, 2001
Posts: 76
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
Ranch Hand

Joined: Jun 12, 2001
Posts: 76
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
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

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

Joined: Jun 12, 2001
Posts: 76
I know why Bruce wrote a "Bitter" book now.
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Bitter Java and Patterns