Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   Static Variables and JAR Files (http://www.velocityreviews.com/forums/t595793-static-variables-and-jar-files.html)

Jason Cavett 03-03-2008 07:23 PM

Static Variables and JAR Files
 
I am curious - does the scope of static variables carry across
different JAR files?

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

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

Knute Johnson 03-03-2008 07:37 PM

Re: Static Variables and JAR Files
 
Jason Cavett wrote:
> I am curious - does the scope of static variables carry across
> different JAR files?
>
> 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...
>
> 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.)


I'm curious how you instantiate a static object? What tool are they using?

--

Knute Johnson
email s/nospam/knute/

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Lew 03-03-2008 08:13 PM

Re: Static Variables and JAR Files
 
Knute Johnson wrote:
> Jason Cavett wrote:
>> I am curious - does the scope of static variables carry across
>> different JAR files?
>>
>> 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...
>>
>> 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.)

>
> I'm curious how you instantiate a static object? What tool are they using?


The scope of a static class variable is the entire execution of the JVM once
the class is loaded. Its accessibility is that declared for it.

When you say "ObjectX is instantiated twice and has two separate values",
first of all, instance names are supposed to begin with a lower-case letter.
Anyway, do you mean there are two simultaneous instances of
'BaseClass.ObjectX' (we really have to improve these names!)? Or do you mean
there is one variable 'BaseClass.ObjectX' that points to different objects at
different times?

If it's the first case, two simultaneous instances of the "same" static
variable, it's because the class was loaded two different times by two
different ClassLoader instances. That causes the "same" class to actually be
two different classes, one belonging to each ClassLoader.

If it's the second case, the same variable but it points to different objects
at different times, it's because something changed what the variable points to
after it was set the first time.

--
Lew

Mark Space 03-03-2008 08:23 PM

Re: Static Variables and JAR Files
 
Jason Cavett wrote:

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


Obviously, when you make a new class via inheritance, it gets it's own
copy of the static variable. So there will be one static for the parent
class, and one for the child class. The static is a "class variable"
and since there are two classes (parent and child) there are two static
variables.

There could be other things going on. The tool may be using
ClassLoaders to load the jar files. When a separate ClassLoader is
used, classes loaded under separate ClassLoaders are separate classes.
Even if there was no inheritance involved, there may still be two
separate ObjectX and two copies of the static variable. If this is the
case, there will also be two copies of the class object itself (it gets
loaded twice, to separate memory areas) which is the root cause of this
particular static issue.


You may need to look at the documentation of the tool you are using, and
decide how you need to correctly deal with this situation. Just
curious: what tool are we talking about here? Like maybe a web container?


There could be other issues too. Fire up the debugger, read the source
code, decompile some tool code, or bug the manufacturer support site.
Stuff happens.

Eric Sosman 03-03-2008 08:24 PM

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

Eric Sosman 03-03-2008 09:05 PM

Re: Static Variables and JAR Files
 
Mark Space wrote:
> Jason Cavett wrote:
>
>> 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.

>
> Obviously, when you make a new class via inheritance, it gets it's own
> copy of the static variable. So there will be one static for the parent
> class, and one for the child class. The static is a "class variable"
> and since there are two classes (parent and child) there are two static
> variables.


Please predict the output of this simple demonstration, and
then test your prediction:

class Foo {
static int count;

public static void main(String[] unused) {
Foo.count = 1;
Bar.count = 2;
System.out.println("Foo.count = " + Foo.count);
System.out.println("Bar.count = " + Bar.count);
}
}

class Bar extends Foo {
// Mark says a copy of `count' is inherited here
}

If Foo.count and Bar.count are two distinct variables, the
output will show two different values. If it shows the same
value for both, they cannot be distinct. Place your bets!

--
Eric.Sosman@sun.com

Thomas.a.mcglynn@nasa.gov 03-03-2008 09:13 PM

Re: Static Variables and JAR Files
 
On Mar 3, 3:23 pm, Mark Space <marksp...@sbc.global.net> wrote:
> Jason Cavett wrote:
> > 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.

>
> Obviously, when you make a new class via inheritance, it gets it's own
> copy of the static variable. So there will be one static for the parent
> class, and one for the child class. The static is a "class variable"
> and since there are two classes (parent and child) there are two static
> variables.
>


To clarify this since I think it could be misinterpreted:
If you try the following program:

class A {
static String var = "ClassA";
}
class B extends A {
}

public class Test {
public static void main(String[] args) {
B.var = "SetInProgram";
System.out.println("A.var is:"+A.var);
System.out.println("B.var is:"+B.var);
}
}

The output of this program

A.var is:SetInProgram
B.var is:SetInProgram

shows that there is only one field even though B extends A. I can add
a declaration to B:

class B extends A {
static String var = "ClassB";
}

Now when I run this I get:

A.var is:ClassA
B.var is:SetInProgram

The definition in B hides the one in A (or 'shadows' I'm never quite
sure of which terminology is used where) -- though a user could still
reference it as A.var.

So regardless of the number of times we extend a class, we declare
only a single instance of its static fields. However if the new class
does not hide the original field, we can use a new name for the field.

Regards,
Tom McGlynn

Lew 03-03-2008 09:15 PM

Re: Static Variables and JAR Files
 
Mark Space wrote:
> Obviously, when you make a new class via inheritance, it gets it's own
> copy of the static variable. So there will be one static for the parent
> class, and one for the child class. The static is a "class variable"
> and since there are two classes (parent and child) there are two static
> variables.


This isn't exactly correct. If the child class does not declare a hiding
static variable then there is only the parent-class variable. There isn't by
default a duplicate version in the child class.

--
Lew

Mark Space 03-03-2008 09:37 PM

Re: Static Variables and JAR Files
 
Eric Sosman wrote:
> Mark Space wrote:
>> Obviously, when you make a new class via inheritance, it gets it's own
>> copy of the static variable. So there will be one static for the
>> parent class, and one for the child class. The static is a "class
>> variable" and since there are two classes (parent and child) there are
>> two static variables.

>
> Please predict the output of this simple demonstration, and
> then test your prediction:


Well clearly I was mistaken. That's pretty frustrating too because I
looked this up before I posted, and the documentation and examples
seemed to indicate that there would be a copy of a static variable.

Even the JLS doesn't really say, it just says that non-private fields
are inherited. I'm not sure how one is supposed to determine when
documentation, including the JLS, should be taken at face value and when
one has to experiment carefully to determine what the docs actually meant.

I'm not sure what else to add, other than I'm really fuming over having
missed that.

Eric Sosman 03-03-2008 09:58 PM

Re: Static Variables and JAR Files
 
Mark Space wrote:
> Eric Sosman wrote:
>> Mark Space wrote:
>>> Obviously, when you make a new class via inheritance, it gets it's
>>> own copy of the static variable. So there will be one static for the
>>> parent class, and one for the child class. The static is a "class
>>> variable" and since there are two classes (parent and child) there
>>> are two static variables.

>>
>> Please predict the output of this simple demonstration, and
>> then test your prediction:

>
> Well clearly I was mistaken. That's pretty frustrating too because I
> looked this up before I posted, and the documentation and examples
> seemed to indicate that there would be a copy of a static variable.
>
> Even the JLS doesn't really say, it just says that non-private fields
> are inherited. I'm not sure how one is supposed to determine when
> documentation, including the JLS, should be taken at face value and when
> one has to experiment carefully to determine what the docs actually meant.
>
> I'm not sure what else to add, other than I'm really fuming over having
> missed that.


Standardese can sometimes be as opaque as a meter of mud.
Perhaps the thing to remember here is that "inherit" does not
mean "make a copy of." The subclass "inherits" the accessible
members of its superclasses, but that doesn't mean it makes
its own local copies of them. They continue to "reside in" or
"belong to" the superclasses, although they can be accessed
through the subclass.

--
Eric.Sosman@sun.com


All times are GMT. The time now is 08:02 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.