>Defensive programming is a strategy where you may put in
“extra” code to just in case the world is not perfect.
For example, the defensive programmer puts in assert()s
to check invariants that are inconceivable to fail
and explicit tests for invariants that could conceivably
Mr. Goetz is down on explicit nulling, as generally pointless.
But after minor collections the new generation
includes objects that aren’t necessarily alive but can’t be reclaimed, either because they are directly alive, or because they are within or referenced from the old generation according to
So when dealing with a large, long-lived, dynamic data structure that is passed around various methods (think of a big DOM or, if it helps, an unwanted haggis brought by a Scottish aunt), you might find that some of its objects are old generation and some are in the new. In that case,
the defensive programmer may
decide to have a cleanup method at the root object of the data structure to traverse the data structure to some depth, to reduce the chances that new generation objects have
references from the old. To give the minor collector
The defensive programmer might also decide to explicitly null the references as soon as possible so that the object is not alive if there is a full GC before the end of the method or the object with the reference.
Whether you think the example is a kind of exceptional case
obviously depends on what kind of application you think is
normal. Java has been well designed for servers
and small applications, which fits in well with Sun and IBM’s
web-client/server architecture. Indeed, much advice
on the Web tacetly assumes servers or applets; fair
enough. But those of us making
desktop applications using Java sometimes have
We like minor collections and want them to be as effective as possible, and we want to
system.gc() to encourage major collections to
occur at times that the user is at rest:
for example, when opening the first file and
whenever a large file is closed.
(Contrast this with Mr. Goetz’s suggestion of using -XX:+DisableExplicitGC, though he has
a typically good point that libraries should avoid
unconditional system.gc(): leave it
to your GUI code.)
Now, you should at this stage be thinking “Mmmmaybe, but
surely profiling is the better way to go: only fix problems that you can see actually exist, not phantom ones!”
This is where defensive programming comes in:
the defensive programmer thinks “Well, the trouble
with profiling is the trouble with most empirical
approaches: they may be focussing on behaviour that is
unexpected or wrong rather than behaviour that is suboptimal” because the performance of large, multi-threaded
desktop applications can be quite hard to capture.
(If your problems occur because you are fondling the
nether limits of your memory, your profiler might
be straining also.)
Actually, in many cases you may not be using
a profiler at all, for whatever reason. If you are not
using a profiler, then defensive programming may
reduce the effect of some problems (such as unreleased
listeners) that profiling makes obvious. If you are
using a profiler, defensive programming may be worth
it just to smooth out lumps in performance and
reduce the application developer’s nightmare: when
the user suddenly has a data set and use-pattern that
brings out the worst in your application.
So I suspect that
sometimes explicit nulling of references is defensible,
sometimes cleanups may help the minor collector,
and sometimes the dreaded System.gc()
is appropriate. So what about the other main point in
the article, against object pooling?
This comes from what looks like an
at Java One by the wonderfully named
Dr. Cliff Click. Dr. Click’s page 30 says
pooling “loses for small objects”,
“a wash for medium objects (Hashtables)” and
a “win for large objects”.
But in Mr. Goetz’s article this becomes
“object pooling is a performance loss for all but the most heavyweight objects”, which I think is a
little too enthusiastic, certainly for
single-CPU desktop systems.
In the more tolerant ’70s, one of my dear
old Dad’s business partners used to sport a
badge “How dare you presume I’m a heterosexual!”
May this is a good slogan for Java desktop application
developers to adapt towards people writing technical
material: “How dare you presume
I’m writing a servlet!”
* Well, at least not for the kinds of desktop
applications I work on.
What are your favourite techniques for defensive programming?