observant. It makes us communicate. It helps us to step beyond our daily grind
to make the fundamental process changes that are required to be successful.
Most of the antipatterns in Bitter Java have a relatively limited focus com-
pared to the more general antipatterns in the AntiPatterns text. Each is
applied to the server-side programming domain, which is popular right now
and young enough to have a whole new set of common mistakes. Our hope is
that this topic will continue the evolution of the study of antipatterns and
bring it into the Java community.
The Bitter Java approach
Bitter Java will take a set of examples, all related to a simple Internet message
board, and redesign them over many chapters. Each iteration will point out a
common antipattern and present a refactored, or redesigned, solution that
solves the problem. In many cases, there may still be problems in the refac-
tored solution. In most cases, these problems are addressed in later chapters.
The others are left as an exercise for the reader. Regardless, the focus of the
antipattern is to refactor a single problematic element.
The focus of Bitter Java is on server-side programming. The base architec-
ture uses common server-side standards of servlets, JSP s, Java connectors, and
EJB s. Where possible, the solutions are not limited to any vendor, though EJB
implementations are currently platform specific.
Bitter Java tools
Based on my experience, I have chosen VisualAge for Java, WebSphere, and
DB2 because the software and support are readily available to the authors. All
of the implementations stress open Java designs and software architectures.
Free, open alternatives to our software include:
The home page for Java, with pages for base toolkits and specifications
A free servlet container, for the execution of servlets and JSP s either in a
jakarta.apache.org / tomcat / .
BEA Systems' WebLogic also supports all of the classes and constructs used
in this topic, though they have been tested only on the original toolset. We do
use the IBM database drivers (and I feel that the native database driver is
almost always the best option), but we do not use the IBM -specific framework
for databeans or servlet extensions, opting for the open counterparts instead.