Re: Static Variables and JAR Files
Jason Cavett wrote:
I am curious - does the scope of static variables carry across
different JAR files?
You're asking a rather detailed question, so it would be
good to ask it in precise language. What, exactly, do you
mean by "scope?" You don't seem to be using the word in the
way the Java Language Specification does.
Here's the issue:
BaseClass is in "BaseClasses.jar"
ExtendedClassA extends BaseClass is in "AnotherPackage.jar"
ExtendedClassB extends BaseClass is in "EvenAnotherPackage.jar"
BaseClass has a static object (ObjectX). Now, normally, this static
object is static across all of the subclasses. However...
Precision again: What do you mean by "static object?" As
far as I can see, objects cannot be static. I *think* what you
mean is that BaseClass has a static member variable that refers
to an instance of the ObjectX class.
These JAR files (AnotherPackage and EvenAnotherPackage) are being read
in by a separate tool. When ExtendedClassA and ExtendedClassB are
used within the context of this tool, ObjectX is instantiated twice
and has two separate values. As far as I can tell, the tool runs
ExtendedClassA and ExtendedClassB within the same JVM, so I am unsure
of what is going on.
Does anybody have any insight into what is going on here? (Sorry for
being vague. I'm not actually working the project, but I'm curious
from an academic standpoint. Another group ran across this problem
today.)
A class is identified by its fully-qualified name *and* by
the ClassLoader instance that loaded it. If two distinct loaders
load "net.worth.Zero" -- even if they load it from the very same
Zero.class file -- there will be two distinct classes both named
"net.worth.Zero" floating around in the JVM. Something like an
IDE might find this convenient, because it would allow you to
edit and recompile Zero.java and then load the newly-compiled
class without restarting the JVM or somehow force-unloading the
old class.
This "separate tool" you speak of may be using multiple class
loaders for one reason or another. You could try getClass() on
both the ObjectX instances to find out whether they are actually
of different classes.
--
Eric.Sosman@sun.com