This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Artima Forums.

I hate to be critical of this, however I've been forced to live in such a world as your article talks about. I find this method of development allows for the breaking of the OOD paradigm, and allows the developer to revert back to procedural type programming. The main issue with these statics comes into play when doing distrubuted computing over the internet. When an applet starts and the classes are loaded the statics are set. These values will change throughout the life of the applet but it's not until the browser is close and reopened or the memory gets so full that GC finally occurs that these classes get reloaded thus resetting the static. Simple advancing to another HTML page, or closing your applet does no good. When the VM starts back up, there are the last values these statics contained.While static have there place, I find that they are more of a crutch to help those coming from a procedural background make the transition to OOP. But as with any crutch you must get rid of it or it becomes an obsticle not a help. In this case you never really make the full switch to OOP, and your code tends to be forcing procedural ideas into a OO language. Thread saftey is a concern but by using method variable for transaction processing instead of instance variable the data segment for each method call is separate and thread saftey is a non-issue.