|
|
An annotation-based persistence framework
The getter/setter idiom has always been problematic; it allows
too-broad access to the implementation of your classes, degrading
maintainability as a consequence. The J2SE 5.0 annotation (or
metadata) feature provides an alternative. Rather than using
introspection to find get/set methods, you can "tag" an object with
an annotation and then access that annotation at either compilation
or at runtime. This article both describes the annotation mechanism
and presents the output side of an XML-based persistence mechanism
that uses annotations to tag persistent classes and fields.
Allen Holub,
March 2005
Write custom appenders for log4j
The Apache Software Foundation's log4j logging library is one of
the better logging systems around. It's both easier to use and more
flexible than Java's built-in logging system. This article shows
you how to extend log4j with a custom "appender," the part of the
system that actually writes the logging messages. This article also
provides a simple example of Java's socket APIs and multithreading
capabilities.
Allen Holub,
December 2004
More on getters and setters
Allen Holub's past Java Toolbox column, "
Why Getter and Setter Methods Are Evil," discussed the downside
of the getter/setter idiom. That article presented a design-level
solution. (By keeping your design in the problem domain as long as
possible and using dynamic modeling techniques like CRC (classes,
responsibilities, collaboration) modeling, the getter/setter
methods tend not to show up at all.) This article expands on the
previous article by providing one of several possible programmatic
solutions to the get/set-elimination problem. In particular, Allen
demonstrates how to use the Gang of Four Builder design pattern to
construct both Web-based and client-side user interfaces without
exposing your object's implementation to the entire program.
Allen Holub,
January 2004
Create client-side user interfaces in HTML, Part 2
This "Create Client-Side User Interfaces in HTML" series continues
by examining the HTMLPane sources. Part 2 offers
examples of how to customize the JEditorPane to
support custom tags and also provides an extended description of
the Factory Method design pattern.
Allen Holub,
November 2003
Create client-side user interfaces in HTML, Part 1
This article presents a variant on Swing's JEditorPane
that makes it possible to specify an entire screen of your
client-side user interface (UI) in HTML. JEditorPane is designed to
let you put an HTML text component inside a dialog box, not to
specify the entire contents of the dialog box in HTML. In practice,
this class makes it vastly easier to create complex user interfaces
than does Swing/Abstract Window Toolkit (AWT)'s standard
containment-and-layout-manager architecture.
Allen Holub,
October 2003
Why getter and setter methods are evil
The getter/setter idiom is a commonplace feature in many Java
programs. Most of these accessor methods, however, are unnecessary
and can severely impact your systems' maintainability. Using
accessors violates the basic object-oriented (OO) principle of
encapsulation, so you should avoid them. This article discusses
getter/setter cons and offers an alternative design methodology.
Allen Holub,
September 2003
Why extends is evil
Most good designers avoid implementation inheritance (the
extends relationship) like the plague. As much as 80
percent of your code should be written entirely in terms of
interfaces, not concrete base classes. The Gang of Four Design
Patterns book, in fact, is largely about how to replace
implementation inheritance with interface inheritance. This article
describes why designers have such odd beliefs.
Allen Holub,
August 2003
Solve the date-selection problem once and for all
The Java Toolbox column returns with this tutorial
about a date-selection widget that displays a calendar and lets you
select a date by clicking on it. It heavily uses the Gang of Four
Decorator design pattern, so it provides a good example of that
pattern at work; the article is as much about Decorator as it is
about calendar widgets. The associated code demonstrates how to use
Java's java.util.Calendar class and how to build a
lightweight Swing dialog with custom framing and title bars.
Allen Holub,
July 2003
Warning! Threading in a multiprocessor world
Many authors (myself included at one point) advocate the
double-checked locking idiom to access a Singleton object in an
intuitively thread-safe way. Unfortunately, for counterintuitive
reasons, double-checked locking doesn't work. Double-checked
locking, in fact, is characteristic of a whole slew of so-called
tricks that purport to eliminate synchronization overhead. They
seem to work on an intuitive level, but they don't work at all in
practice. The situation is made even worse in multiprocessor
environments, since a trick that indeed works on a single-processor
box oftentimes won't work correctly on a multiprocessor box. This
article explains why. Warning: it's assumed that you know how
synchronized works. (2,000 words)
Allen Holub,
February 2001
Programming Java threads in the real world, Part 2
This article, the second in a multipart series on threads,
discusses the perils that can arise when you approach
multithreading in a naive way. As is the case with the entire
series, this article assumes reader familiarity with the basic
thread-related parts of Java: the synchronized keyword
and monitors, wait(), notify(), the
basics of using the Thread class, and so forth. Here,
Allen focuses on the more advanced problems encountered when
programming Java threads in the real world.
Editors' note: Due to the overwhelming and
enthusiastic response from readers who read Allen Holub's Part 1
article on threads, JavaWorld has created a regular column
by this author. We hope you enjoy this debut article of
Java Toolbox! (3,800 words)
Allen Holub,
October 1998
Programming Java threads in the real world, Part 1
Programming Java threads isn't nearly as easy (or as
platform-independent) as most books would have you believe, and all
Java programs that use the AWT are multithreaded. This article is
the first in a series that discusses the things you need to know to
program threads in the real world. The article assumes you
understand the language-level support for threads (the
synchronized keyword, how monitors work, the
wait() and notify() methods, and so on)
and focuses on the legion of problems that arise when you try to
use these language features. (3,400 words)
Allen Holub,
September 1998