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.

Message:

Hmm...

Posted by Bill Venners on 26 Feb 1999, 6:58 AM

> 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.

Perhaps I should re read my article, because I intended to put
statics in their place and encourage object-oriented thinking. I
agree that statics can be tempting for programmers used to
procedural thinking. The way I tried to present statics to just
that kind of programmer is as a way of doing information hiding,
primarily information hiding of objects. I attempted
to warn procedurally-inclined programmers away from what some
author (who I can't remember off hand) called "modulitus",
treating classes as if they were objects.

As far as the static state vs garbage collection of classes goes,
the answer is complicated because the original JVM and JL specs
were fuzzy on when class GC is allowed to occur. The specs
were later tightened, but some JVM implementations (older ones)
didn't adhere to the tightened rules (because they came out
before the rules were tightened.) I think this is even true of
some of the JVMs that came with certain versions of the JDK.

The new rules are, a class can only be unloaded if there are no
references to any classes, objects, the class loader object,
and the Class instances that were created when the
class loader object loaded the types. When everything is
unreferenced, the whole thing may be unloaded: all types loaded
by that class loader object (into that name space), all Class
objects, any instances of classes loaded into that name space,
and so on. It will either all be unloaded together, or not
unloaded at all.

Here's the hard thing to get: You will never lose any static
state (under the tightened rules) that you can get at anyway.
Because if you can get at it, it won't be unreferenced and it
won't get GC'd. If you just say,

Fred.yabbaDabbaDoCount

where yabbaDabbaDoCount is a public static
variable of Fred you will get the state of that
static variable in the current name space. If there
is a Fred in another name space for which the
program no longer holds any references, you can't get at the
static state of that Fred. Name spaces are kind
of complicated, but I try and fully describe how they work in
Chapter 8 of my JVM book, which is reprinted online at

http://www.artima.com/insidejvm/linkmod.html

The trouble with all this is that there are JVMs out there that
will unload classes loaded into any name space via forName(),
so that's where you have to be careful. If you don't know what
VM you're going to be running on, and you're writing a program
to JDK 1.1 or 1.0, you need to think about having a thread run
in a class loaded via forName() or keeping a reference to an
instance to keep that class from being unloaded in those old
JVMs.

bv