Java Reference
In-Depth Information
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.
1.5.1
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.
1.5.2
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.