A few months ago I wrote an editorial on the touchy subject
of proper testing (Vol. 8, issue 6). Thanks to you there was much
support (and a volume of information from Parasoft and how JTest
linked with unit testing; this opened my eyes!). No one disagreed
with me, but somehow I can't see unit-testing libraries being
included with the next update of the software development kit.
This brings me to another touchy subject - proper logging. If
you administer any type of Unix-like system, you'll be used to
working with log files in some form or another. Ever thought of
logging your Java programs like that? Okay, the majority of us have
watched everything spew out of System
.out.println() or printStacktrace() at some time or another. No
matter what the class of application - high performance, low
performance, high visibility, or just something on your own machine -
it doesn't matter. You have to log your messages properly.
There are a number of logging packages out there. The main
one is in the 1.4 SDK (have a look at the java.util.logging package),
Log4J by the Apache Jakarta project, and then there are some lesser
known loggers like LN2. All do the same thing: record information to
make your life easier.
The reason people don't log info is pretty much the same
reason people don't do proper testing: it's a mindset thing. The aim
here is to create history to prove that your application is running
well; it also helps you trace back errors and warnings. Watching your
entire history hurl itself onto your console output is not real help
to you or anyone else.
Archive your logs daily no matter how big they are. If you
use or have used Apache, you may have come across a utility called
rotatelogs, which organizes your log files and resets the current one
for a new day or if the log file size reaches a certain size. My logs
are generated daily, then, when the month is up, I burn them to CD.
If there is any change of data, that transaction should be
logged. You need a user trail to see what is happening. It's not
snooping; it's protecting yourself. What happens when someone claims
an action happened when you know it didn't? You check the logs.
Another oversight is the maintenance of third-party Java
libraries. With the amount of active project work on SourceForge, you
should be updating these JAR files as much as you can. What I tend to
see is a trail of old and unsupported libraries used in applications.
What would happen if I updated to the most recent JAR file? Would the
application still function? There's usually one way to find out.
A set of mirror sites that had all the up-to-date JAR files
would be a good idea. Then we could update periodically. My favorite
example of this is the apt-get program that's used in Debian Linux.
It's one of the best updaters I've seen. The onus is still on the
system administrator to update the package list first. When you run
apt-get, it checks dependencies and related packages; you can also do
first time installs with it.
Our responsibility does not stop once our applications are
shipped to clients. We still provide a service, as we are a
service-oriented industry. We have a duty to inform, update, and
educate customers as we see fit and do it with a large amount of
respect and politeness.
If we can get these two issues cracked, logging and
dependency, we all stand a pretty good chance of extending our
careers and making Java the platform it deserves to be -
References Log4J: http://jakarta.apache.org/log4j
About The Author
Jason Bell is the senior programmer for a B2B portal. He's also a
keen supporter of people reading the API docs before asking
questions. In his spare time he's involved with building RSS