Re:EJB is REALLY Bitter
on
Bitter EJB
·
· Score: 1
Thanks for all of the comments. I'd like to make a couple of points.
First, all of the authors on the team see EJB as just another tool in the box. If it makes our lives easier, we use it. If not, we'll reach for something else.
Second, I do think that when most people say "I hate EJB", they basically mean "I hate EJB entity beans." MDB and session beans are fair abstractions.
A (late) kayaker named William Nealy used to have a book that contained a section on running rivers in flood. He had to dance around the issue of whether he was actually endorsing the practice of running rivers in flood. So, he said something like this. "If you asked me if you should run rivers in flood, I'd say 'No. But if you do, here are some things that you should know.'"
I find myself in a similar position with this book. EJB is a massive framework, and fairly invasively. I'm not a huge fan, but believe that facades with MDB or session beans are reasonable. If you can live with those limitations, check out Bitter EJB. You'll be glad you did. Even if you're fairly experienced, we're likely to lead you away from one land mine that you've not seen before.
If not, I encourage you to check out some alternatives. For persistence, I'm a big fan of JDO. Kodo is a fabulous product, and is the reason that I recruited Patrick Linskey to the team: he's CTO of that company. For a generic container, check out Spring, or maybe Pico. They are light weight containers that let you do some amazing stuff, with containers that are light enough for a JUnit test case. And your objects don't depend on the container.
One final point. I'm proud of the fact that the two Bitter books have personality. Too many editors try to strip personality out of a book, for fear of offending the audience. I'd rather offend you than bore you. So if you'd rather be bored than offended, please pass.
Take care, and thanks to all who have made this book a success.
You said: "The facade pattern, OTOH, is designed to make life simpler for programmers, potentially at the cost of execution speed."
It depends on where you apply your facade, no? A facade can also shift distributed boundaries away from expensive iterative interfaces. Use a UML OID to find out where. Look in the book for an example of the math.
If you take 20 round trips to a remote entity EJB and replace with 1 round trip session bean that wraps 20 local method calls to the entity EJB, you've added a layer.
Is it slower? Absolutely not. You more than offset the additional layer with the distributed communication costs.
I stand behind the facade as a good performance enhancer for this instance...and so do the writers of other best sellers (Core series, EJB design patterns, Mastering EJBs to name 3.)
Tate "stole" antipatterns.
on
Bitter Java
·
· Score: 1
I freely admit to stealing the term antipatterns. A co-author of Antipatterns wrote the forward...Skip McCormick III. (Enjoyable book, by the way.)
I like antipatterns because they capture the simplicity of patterns in a new context: literary descriptions of common traps that do damage.
You miss the point entirely. Antipatterns are all around us. Learning to analyze and correct (refactor) systemic problems makes you a better programmer. Advanced programmers learn this from experience. Intermediate programmers can become advanced either by repeating mistakes, or reading about mistakes of others.
The Java community has already embraced design patterns...they are everywhere. I recommend Floyd M.'s book on EJB design patterns. The Java community has only loosely recognized antipatterns. I think that's a mistake.
Other industries, most notably manufacturing, use antipatterns extensively. Think about programs like Zero Defects or Quality Circles that strive to recognize and correct systemic problems. Manufacturers use design patterns (like just-in-time), but they also recognize the need for antipatterns.
Think of antipatterns as a way to correct what's wrong, and design patterns as a way to do things right the first time. In short, different needs for different tasks.
Java was a compromise. Keep the timing in mind. Microsoft was dominating corporate development with Visual C++. Object oriented programming was choking under the weight of pointer arithmetic, memory management, include files and multiple inheritance.
SUN needed C++ syntax to rapidly build the community. SUN also needed to make some typing compromises to be more familiar to C++ users. C++-like syntax; SmallTalk-like object model. Without those communities, Java was dead out of the gate.
But...that does leave some holes in the base language. J2EE has a few holes itself, but we're moving forward.
Thanks for the kind words.
on
Bitter Java
·
· Score: 5, Interesting
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.
Slashdot Mirror
Thanks for all of the comments. I'd like to make a couple of points. First, all of the authors on the team see EJB as just another tool in the box. If it makes our lives easier, we use it. If not, we'll reach for something else. Second, I do think that when most people say "I hate EJB", they basically mean "I hate EJB entity beans." MDB and session beans are fair abstractions. A (late) kayaker named William Nealy used to have a book that contained a section on running rivers in flood. He had to dance around the issue of whether he was actually endorsing the practice of running rivers in flood. So, he said something like this. "If you asked me if you should run rivers in flood, I'd say 'No. But if you do, here are some things that you should know.'" I find myself in a similar position with this book. EJB is a massive framework, and fairly invasively. I'm not a huge fan, but believe that facades with MDB or session beans are reasonable. If you can live with those limitations, check out Bitter EJB. You'll be glad you did. Even if you're fairly experienced, we're likely to lead you away from one land mine that you've not seen before. If not, I encourage you to check out some alternatives. For persistence, I'm a big fan of JDO. Kodo is a fabulous product, and is the reason that I recruited Patrick Linskey to the team: he's CTO of that company. For a generic container, check out Spring, or maybe Pico. They are light weight containers that let you do some amazing stuff, with containers that are light enough for a JUnit test case. And your objects don't depend on the container. One final point. I'm proud of the fact that the two Bitter books have personality. Too many editors try to strip personality out of a book, for fear of offending the audience. I'd rather offend you than bore you. So if you'd rather be bored than offended, please pass. Take care, and thanks to all who have made this book a success.
It depends on where you apply your facade, no? A facade can also shift distributed boundaries away from expensive iterative interfaces. Use a UML OID to find out where. Look in the book for an example of the math.
If you take 20 round trips to a remote entity EJB and replace with 1 round trip session bean that wraps 20 local method calls to the entity EJB, you've added a layer.
Is it slower? Absolutely not. You more than offset the additional layer with the distributed communication costs.
I stand behind the facade as a good performance enhancer for this instance...and so do the writers of other best sellers (Core series, EJB design patterns, Mastering EJBs to name 3.)
I like antipatterns because they capture the simplicity of patterns in a new context: literary descriptions of common traps that do damage.
You miss the point entirely. Antipatterns are all around us. Learning to analyze and correct (refactor) systemic problems makes you a better programmer. Advanced programmers learn this from experience. Intermediate programmers can become advanced either by repeating mistakes, or reading about mistakes of others.
The Java community has already embraced design patterns...they are everywhere. I recommend Floyd M.'s book on EJB design patterns. The Java community has only loosely recognized antipatterns. I think that's a mistake.
Other industries, most notably manufacturing, use antipatterns extensively. Think about programs like Zero Defects or Quality Circles that strive to recognize and correct systemic problems. Manufacturers use design patterns (like just-in-time), but they also recognize the need for antipatterns.
Think of antipatterns as a way to correct what's wrong, and design patterns as a way to do things right the first time. In short, different needs for different tasks.
Bruce Tate, author of Bitter Java
Java was a compromise. Keep the timing in mind. Microsoft was dominating corporate development with Visual C++. Object oriented programming was choking under the weight of pointer arithmetic, memory management, include files and multiple inheritance. SUN needed C++ syntax to rapidly build the community. SUN also needed to make some typing compromises to be more familiar to C++ users. C++-like syntax; SmallTalk-like object model. Without those communities, Java was dead out of the gate. But...that does leave some holes in the base language. J2EE has a few holes itself, but we're moving forward.
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.