instances ant staic attributes

[Volker Raum]

Hi all,
i got a very simple question.

imagine the following class:

class test
{
public static int attr = 0 ;
}

Is it possible to have 2 instances of this class within ONE Virtual
machine (standard machine, no tricky faked machine) where the content of
attribute attr differs?
Using Classloader i.e. ?

Example code would be good.

Volker

 

[Phillip Lord]

Volker> Hi all, i got a very simple question.

Volker> imagine the following class:

Volker> class test {
Volker> public static int attr = 0 ;
Volker> }

Volker> Is it possible to have 2 instances of this class within ONE
Volker> Virtual machine (standard machine, no tricky faked machine)
Volker> where the content of attribute attr differs? Using
Volker> Classloader i.e. ?

Volker> Example code would be good.

Yes.

Generate a class loader. Load class test. Generate another class
loader. Load class test again.

You now have two classes within one JVM. In this sense the class
system within the JVM (which depends on the fully qualified name, and
the class loader) is richer than in Java (which depends only on the
FQN).

The thing to remember though is that they are using different class
loaders, so generally the two independent classes will not interact
with each other.

Phil

 

[Markus Reitz]

Hi,

what about using two class loaders?

Pseudo-code:

new URLClassLoader(<Path to the class>).loadClass(<Name of the
class>).newInstance()

Markus

 

[Franck Meyer]

Semantically I believe that this is not a good idea. "Static attribute"
means that the value is shared by All instances of the class.
So, even if you (or someone else) find a workaround, I think you would
better forget it. Instead, do it differently for example don't declare
your attribute as static.

FM.

 

[Thomas G. Marshall]

Hi all,
i got a very simple question.

imagine the following class:

class test
{
public static int attr = 0 ;
}

Is it possible to have 2 instances of this class within ONE Virtual
machine (standard machine, no tricky faked machine) where the content
of attribute attr differs?
Using Classloader i.e. ?

Example code would be good.

No, example code would be very very bad.

I would suggest that what you are attempting here, which is probably
possible through class loading smoke and mirrors, is a maintainability
disaster waiting to happen.

Maybe consider a different way around this issue. If what you want are two
separate class heirarchy each with their own "static" then consider a
singleton approach, or similar.

In general, trying to break the rules like this, and I do believe that it
would be breaking the rules, is a terrible idea. If someone disagrees with
this example, I'd like to know why. Thanks.

 

[Phillip Lord]

Thomas> No, example code would be very very bad.

Thomas> I would suggest that what you are attempting here, which is
Thomas> probably possible through class loading smoke and mirrors,
Thomas> is a maintainability disaster waiting to happen.

Thomas> Maybe consider a different way around this issue. If what
Thomas> you want are two separate class heirarchy each with their
Thomas> own "static" then consider a singleton approach, or similar.

Thomas> In general, trying to break the rules like this, and I do
Thomas> believe that it would be breaking the rules, is a terrible
Thomas> idea. If someone disagrees with this example, I'd like to
Thomas> know why.

I do. Its actually a very good idea. If you want to see examples of
its use, then have a look at tomcat, or netbeans, both of which
separate modules (or servlets) in this way.

Say I write a servlet which uses statics of some library, and someone
else does the same, by using a different class loader, I can ensure
separation of the two servlets, because the classes of the library
will exist twice, and will not interfere with each other. So, for
example, two servlets could use log4j, and set different root loggers,
even thought they both get this object from the same static.

Of course, it is possible to abuse this, and write bad code as
result. If you start doing this, for example, within code bases which
are supposed to interact, then you are asking for trouble...you will
not be able to tell statically from the code base which class you are
talking about (and remember not only can the duplicated class have
different values, but it can have different methods, different
inheritance, everything...you have two totally different classes).

Phil

 

[Thomas G. Marshall]

Thomas> No, example code would be very very bad.

Thomas> I would suggest that what you are attempting here, which is
Thomas> probably possible through class loading smoke and mirrors,
Thomas> is a maintainability disaster waiting to happen.

Thomas> Maybe consider a different way around this issue. If what
Thomas> you want are two separate class heirarchy each with their
Thomas> own "static" then consider a singleton approach, or similar.

Thomas> In general, trying to break the rules like this, and I do
Thomas> believe that it would be breaking the rules, is a terrible
Thomas> idea. If someone disagrees with this example, I'd like to
Thomas> know why.

I do. Its actually a very good idea. If you want to see examples of
its use, then have a look at tomcat, or netbeans, both of which
separate modules (or servlets) in this way.

Sure, for purposes of providing code that itself interfaces with other code
it can be useful to get into the guts of the system and do things that would
normally be asking for trouble. But I'm betting that those situations are
limited to programming environments, and utilites.

Say I write a servlet which uses statics of some library, and someone
else does the same, by using a different class loader, I can ensure
separation of the two servlets, because the classes of the library
will exist twice, and will not interfere with each other. So, for
example, two servlets could use log4j, and set different root loggers,
even thought they both get this object from the same static.

If this concept doesn't give you an olympic sized case of the willies, then
you're taking the wrong meds.

Of course, it is possible to abuse this, and write bad code as
result.

NO! Really????

If you start doing this, for example, within code bases which
are supposed to interact, then you are asking for trouble...you will
not be able to tell statically from the code base which class you are
talking about (and remember not only can the duplicated class have
different values, but it can have different methods, different
inheritance, everything...you have two totally different classes).

As I said. A maintainability disaster waiting to happen.

 

[Phillip Lord]

Thomas> Sure, for purposes of providing code that itself interfaces
Thomas> with other code it can be useful to get into the guts of the
Thomas> system and do things that would normally be asking for
Thomas> trouble. But I'm betting that those situations are limited
Thomas> to programming environments, and utilites.


The two examples I gave were both container environments, which is
the obvious use.

Thomas> If this concept doesn't give you an olympic sized case of
Thomas> the willies, then you're taking the wrong meds.

No, actually, it doesn't. I can't see a particular problem with this,
in fact it seems to answer a real need. If I install a servlet into a
running tomcat, it seems a positive point in its favour that my
servlet is divorced from any other servlet in the same container. I
can set up logging, using statics, and so can the next person. And the
two do not interfere.

Thomas> NO! Really????

Thomas> As I said. A maintainability disaster waiting to happen.

Again, you are wrong. The maintainability problem is caused by statics
in the first place. Global variables often cause problems. In the
example that I have given, the ability to separate out different
components in a container framework adds to the maintainability, not
removes it.

Of course it is possible to shoot yourself in the foot with such
abilities. Your attitude seems to be "therefore it's always bad". It
clearly is not.

Phil

 

[Thomas G. Marshall]

Phillip Lord <[email protected]> horrified us with:

....[confusing snip: I tried snipping with the attributes in place, but the
conflicting indenting styles was making a mess]...

Thomas> As I said. A maintainability disaster waiting to happen.

Again, you are wrong. The maintainability problem is caused by statics
in the first place.

PRECISELY why you are inviting disaster by making any reference to a static
potentially mean two different ones. Statics can break the OOD paradigm all
by themselves. And now you want duplicate classes, same name, same
everything? Regardless of the partitions you believe are in place, remember
that someone most likely has to read your code some day.

Global variables often cause problems. In the
example that I have given, the ability to separate out different
components in a container framework adds to the maintainability, not
removes it.

If that's what you need, then in general I'd suggest humbly that what you
need are carefully managed dual singletons (dualtons?), with a model change.

Of course it is possible to shoot yourself in the foot with such
abilities. Your attitude seems to be "therefore it's always bad". It
clearly is not.

I can concoct a great use for just about anything bizarre. But remember
that maintainability is about how your code is managed afterward. Having
two copies of the same class each with their own statics:

MyClass.staticOne;

and the reloaded copy

MyClass.staticOne;

Is inviting disaster. Someone is going to try to read a line of code
containing:

MyClass.staticOne

and not know which one it is.