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.

Dependency Rot
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 - indispensable.

References