Chapter 11 ("References in Four Flavors") of Hardcore Java illustrates a recurring problem in
many Java programs, namely the creation of circular reference trees that pin
objects in memory and interfere with garbage collection. The widely held
misconception that a "Java developer does not have to worry about the memory of his program" has led many Java developers to create programs that require excessive amounts of resources. The extra resources consumed by objects
unintentionally pinned in memory are Java's version of a memory leak.
This kind of memory leak can be avoided by the use of weak references and
weak listeners. Weak references are a special kind of reference that do not block
garbage collection. This allows your data objects to hold references to GUI
panels in their property change listeners without blocking the garbage collection
of those panels. Furthermore, it relieves the user of the data object from having
to constantly manage the addition and removal of listeners, which results in code that is
easier to manage. Legacy programs can be easily converted to use weak
listeners. To show how these programs can be converted, consider the following
legacy code:
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.HashSet;
import java.util.Iterator;
import java.util.Set;
public class SomeButtonClass1 {
private final Set listeners = new HashSet();
public void addActionListener(final ActionListener l) {
listeners.add(l);
}
public void removeActionListener(final ActionListener l) {
listeners.remove(l);
}
protected void fireActionPerformed(final ActionEvent event) {
for (final Iterator iter = listeners.iterator();
iter.hasNext();) {
((ActionListener)iter).actionPerformed(event);
}
}
}
This code can easily be converted to use weak listeners with a couple of minor changes:
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.Iterator;
import java.util.Map;
import java.util.WeakHashMap;
public class SomeButtonClass {
private final Map listeners = new WeakHashMap();
public void addActionListener(final ActionListener l) {
listeners.put(l, null);
}
public void removeActionListener(final ActionListener l) {
listeners.remove(l);
}
protected void fireActionPerformed(final ActionEvent event) {
for (final Iterator iter = listeners.keySet().iterator();
iter.hasNext();) {
((ActionListener)iter).actionPerformed(event);
}
}
}
After these three small changes, the listeners don't even need to bother with
removing themselves, if they don't wish to. If they remove themselves, all
will be OK. If they are merely garbage collected, all will still be OK. To
understand how this works in more detail, I encourage you to read Chapter 11 of
Hardcore Java.
7. Replace Integer Constants with Constant Objects or Enums
Chapter 7 ("All About Constants") of Hardcore Java talks about constants in detail. One of the most
important lessons you should carry out of that chapter is that using integers
for option constants is a bad idea. For example, if you want to
create a class that can only take a color of the rainbow as an argument to a
method, using integers for each of the seven colors is the wrong approach. We
show an example of such code here:
public final class RainbowColor {
public final static int RED = 0;
public final static int ORANGE = 1;
public final static int YELLOW = 2;
public final static int GREEN = 3;
public final static int BLUE = 4;
public final static int INDIGO = 5;
public final static int VIOLET = 6;
}
When using integer constants such as these, you might write the following code:
public void doSomething(final int rainbowColor) {
// ...
}
The problem here is that the user can pass you any integer. In order to make
solid code, you will have to check that integer in every piece of code against the
valid integers. This checking code will have to be maintained in several places.
On the other hand, the use of Enums or Constant Objects relieves you of the
need to check, as we see in the revised option constant class:
public final class RainbowColor {
public final static RainbowColor RED = new RainbowColor("RED");
public final static RainbowColor ORANGE = new RainbowColor("ORANGE");
public final static RainbowColor YELLOW = new RainbowColor("YELLOW");
public final static RainbowColor GREEN = new RainbowColor("GREEN");
public final static RainbowColor BLUE = new RainbowColor("BLUE");
public final static RainbowColor INDIGO = new RainbowColor("INDIGO");
public final static RainbowColor VIOLET = new RainbowColor("VIOLET");
final String name;
private RainbowColor(final String name) {
this.name = name;
}
public String getName() {
return this.name;
}
}
With the revised class, no checking is necessary during its use:
public void doSomething(final RainbowColor rainbowColor) {
// ...
}
Since the user cannot create any more instances of the RainbowColor, there is
no need to check anything. Furthermore, since comparisons of the objects are
done by instance instead of by equality, comparisons are extremely fast.
If you have access to JDK 1.5 in your coding environment, enums are the
equivalent of Constant objects, with less code needed from the developer. If you
are stuck writing for an earlier JDK (as many corporate programmers are), you
should investigate and use the Constant object pattern extensively.
Conclusion
These seven techniques are fairly low cost in terms of man hours, and all are
cost-free in terms of equipment and software. They can all be performed by
hand or with freely available software. Although they represent only the tip of
the iceberg of code-quality improvement, they offer a good place to start when
time is tight and quality demands are high. Given the tools at the disposal of
software engineers, there should be no excuse for writing code that is anything
other than solid as stone. This will allow you to concentrate less on finding little
annoying typos and more on the business your customers or employers
use to make money. They will be happier with your code, and you will have to
work less to accomplish the same tasks.
Robert Simmons, Jr.
lives and works as a senior software architect in Germany. He is the author of O'Reilly's Hardcore Java.
O'Reilly Media recently released Hardcore Java.
Chapter 2, "The Final Story," is available for free online.
You can also look at the Table of Contents, the
Index, and the full description of
the book.
For more information, or to order the book,
click here.