Applets and static variables.

Omry...your question is not clear. I don't understand what you exactly need. From what I have understood....you are having static classes in an applet and you are trying to access them thru' the same machine.
   Why should they be static at the first place? Static has to be used only when you are going to run the app from 2 different machines. Only then they are going to be local to the machine. If due to unavoidable reasons you have to keep them static then I would suggest use getXXX() and setXXX() methods. Depending on the condition overwrite them.

listening...

Sasha Maryanovsky.

Omry, you seem to be doing what I have to check myself from doing quite often - pre-diagnosing the problem. Can you say what the actual symptoms are before we get into the causes? What's happening, are you seeing unexpected results? What are the details.

omry_y:

I'm not surprised that (to use your words): "the static variable of one applet gets overwritten by the static variables of the other". At least not if "one applet" and "the other" refer to two different instances of the same class.

If my understanding is correct, then this is not surprising, it is simply the way that static variables work... they are shared among all instances of the class. That includes the same applet appearing on different pages.

So I'm going to do just what you asked that we NOT do, and suggest a re-design. But I'm hoping that it's not going to be too BIG a redesign.

If I understand correctly, your problem is that you want to have access to certain information all over the place, and don't want to have to pass it around everywhere (a good point), or copy it (which could be avoided other ways, but see point #1). So you used static variables and methods... java's closest equivalent to "global variables". But you DON'T want the information to be global across EVERYWHERE, just global to the particular applet instance (ie, the applet on THIS page, not shared with the one on some other page).

So here's what I recomend in the way of a re-write. First of all (and you may already be doing this, I'm not sure), don't deal with each individual variable separately, group them all into a big "globals" object. This way, if you want to change how it's accessed, you'll just have one place to change. So instead of having Widget.foo, and Widget.bar, and Fidget.foobar as separate variables, you have a class called Globals, and an instance called "global", so that the access is Globals.global.foo, Globals.global.bar, and Globals.global.foobar. I might even go one step farther, and write an accessor METHOD for getting Globals.global. So now your accessers in your code would look like this: Globals.get().foo, Globals.get().bar, Globals.get().foobar.

Now that you've done this, all other changes will be easy. In fact, you may even be able to get away with changing nothing but the method Globals.get(). I would say that the next step is to consider just how "global" you want each variable to be. Each variable might be truely UNIVERSAL (across all applets), or global only within a single instance of the applet. There might even be ones which needed to be global across all users of the applet (in which case you need to coordinate with the server). I'm going to assume that you decide that all of your variables need to be global to the particular instance of the applet (the onee on this page), but no broader.

Now that we've decided how broad to make it, things are basically laid out for us. If we had decided to make things global across all applets, we'd make globals be a static variable (ie, Gloabals.get() would read as follows):

    class Globals {
        static Globals globals;
        public static Globals get() {
            return globals;
        };
    }

But that wasn't our decision... we wanted it to be specific to an instance of the Applet. So that's where we put it.

    class MyApplet extends Applet {
        Globals globals;
        init() {
            globals = new Globals(init here);
        }
    }

Now when writing code in the applet, we can access the "globals" as this.globals.foo, this.globals.bar, and this.globals.foobar. Or, instead, we can re-write Globals.get() to handle it for us, adding applet as an extra parameter:

    class Globals {
        public static get(MyApplet applet) {
            return applet.globals;
        }
    }

And this is how I'd probably do it. But I'm guessing that you're looking at this and saying "But I really DON'T want to pass 'applet' around everywhere!". If I were you, I'd stop here. But if you really want to avoid passing applet around everywhere, there IS a solution... make the variables global to the THREAD. (This is more-or-less equivalent to making them global to the applet, but not quite.) If you're really interested in seeing this solution, let me know and I'll add it.

-- Michael Chermside

Sorry to burst into the discussion like this, but Omry and I work together and he's AFK right now, so I though I'd respond for him :-) I hope he doesn't mind...

CEHJ: Omry is quite clear on what is going on and why - he is looking for a way around the proble, he's not looking into understanding the problem - he already understands it. There are no unexpected results, just ones that differ from desirable :-)

mcherm: Hehe, I think you have thought of almost all the solutions we have thought about - unfortunately, most of the "action" happens in the AWT thread, which is shared between the applets (there's just one per JVM) - so making the data global to a thread will essentially make it global to all the classes that perform their duties in the AWT thread :-)

Sasha Maryanovsky.

Oops, forgot 'static' for 'getGlobals'.

mchem : as Sasha stated, we already thought about all of these solutions.

nice thinking.

you are right, since I dont want to pass the applet around, or any other key.

it all boils down to the need to have a static variable (the real info, or a key to the real info) that will be global to the applet that declare it.

CEHJ : with all the respect, bealive me you dont want to dive into details.
I have the problem diagnosed and I clearly understand when it happens, and why.
what I need is a good alternative, or a magical way to achive it without re-designing.

ET3D : nice idea.
i`ll try it and get back to you.

btw : I have more then one applet in my hirarchy, but lets leave it out of it :-)

Excellent idea ET3D - use the applet or the applet frame as the key... :-)

Sasha Maryanovsky.

One of the good questions in EE

:)

omry_y & sasha_mapa:

Ouch. So if the thread trick won't work, we're in trouble. The fundamental issue is to have SOME key which identifies which instance of the applet we are in. If we had anything -- even just an "applet ID #" -- available everywhere, we could use that as a key to a Hashmap of Global objects, which would solve the problem. The shared nature of the event handler thread kinda blows away using threads to identify it, as long as your work is done in the AWT thread. ET3D's idea of using Component.getParent() to drill your way up the component hierarchy to the applet is a good solution as long as you are doing work somewhere where a Component is available, but in general, the code may be executing in arbitrary objects. I'm really beginning to think that you'll have to stoop to passing SOMETHING around, even if it's only a token which is key to a Hashmap.

The fundamental problem, as we've stated it, is for code executing in an arbitrary method of an arbitrary object to figure out which applet it is part of. We have stipulated that it cannot determine it by examining any method parameters. Since the object it is part of is arbitrary, we cannot determine it by examining any instance variables (ET3D's solution relies on the object not being arbitrary). We cannot determine it by examining any static variables of any class, because those would be the same regardless of which applet was being displayed. We cannot determine it by examining the thread we are executing in because that is the AWT-event thread regardless of which applet it is. We cannot determine it by somehow interacting with the page, because to do that would require that we have access to the Applet object which begs the question. We cannot determine it by connecting to the server because the server has no way to identify us. I'm running out of possibilities here! I think if you massage the above paragraph you wind up with an information-theoretic proof that it's IMPOSSIBLE to solve the problem as stated.

So I'd say, go outside the bounds of what was defined. Either try to enforce a solution like ET3D's, which works in "a lot" of cases, or go ahead and pass around something... the Applet object would be one choice, but it could be an arbitrary token you create... it's the same amount of copying (1 pointer) either way.

An interesting issue. Besides this case (the "lazy" programmer who is just trying to avoid passing variables all over the place) this same issue comes up when trying to develop a generalized logging or debugging support class for java. I have developed such things before, and my solution has been to use static accessors (your original solution) with OPTIONAL parameters specifying which [whatever it is -- applet in your case] is "active". For instance, in a logging system, I allowed the calling class to pass itself in so the logger could determine what class generated the log message. If this parameter was ommitted, then the "logging-class" column was left blank in the logging output. Other optional parameters allowed the calling code to specify things like the "user-id" and the "user-session" IF they happened to be available. If no optional parameters were supplied then the logger logged little more than the thread it originated from, the time of the logged event, and the log error message (which was NOT optional!).

-- Michael Chermside

> heyhey, please participate.

the way I do it (sorry - I haven't read the whole discussion)

0. wrap all the specific data in some Configuration object
you can
1. associate Configuration object per Thread
2. associate Configuration object per component
3. pass your Configuration object to all the objects that need it (as constructor parameter for example)

3. is the most universal. 1. is suitable for server side enviroment and allows you some additional flexibility (like keeping a stack of Log objects per Thread). 2. may be the easiest way to solve the problem if you work with GUI objects only.

I've been always LAZY programmer, so I HATE solution 1. but it seems to be the BEST choice in the log run

my 0.02$ :)

"the way I do it (sorry - I haven't read the whole discussion) "

you should, its an interesting one, and not too long.

1 is not good enough, since the action accures in the AWT event thread, and there is one and only one of these.

2 is, in a way, the suggested solution.

about 3, I dont feel like rewriting so much, so that was only a last resort.


10x for your participation! :-)

I've just reserved a seat to see which answer you are going to accept. :) don't have time to discuss right now ...

btw. 3 is the most universal one.

P.S. 3. is suitable for server side apps (servlets too). 2. is good ONLY if you work with visual objects ONLY (which I personally never do)

but you know better your requirements after all.

mcherm, It may be true that there's no solution for arbitrary objects, but considering that methods called from AWT usually have access to a component, and that methods not called from AWT run in their own thread, this can pretty much cover most bases.

There's even a solution for objects that are called in the AWT thread but aren't components, if they are from top level classes (that extend Object). In that case, have them extend some base class of yours, that will contain the reference, and will take it from the thread in its constructor (or will keep a reference to the Thread where it was created).

I can compine 2 and 3.
for most cases, I need the global info in components, but if I need it in an object that is not a component, I can just pass it to it in one of the old fasioned ways.

omry_y:

I agree... this sounds like the right approach. Basically, use Component as ET3D suggests, and this will cover most of the cases. Then pass something (how about a component!) to all the other cases.

-- Michael Chermside

ET3D :  I am trying to do it now, and already I see a major drawback in the approach :
before attempting to get a configuration object, the chain of panels have to be complete, i.e : every panel should have a parent.

this means that I cant access the configuration object in the constructor of the specific panel, because a panel can only have a parent after it was constructed,


a workaround would be to move the contrutor code to addNoify(), and to make sure the constructor code gets called only once, but this introduce global change to the source, which I try to avoid.

if I am forced to make such a change, I`d rather it to be change to pass the configuration object up the chain instead of something so hacky as move the contructor to the addNotify().

well guys, look like we have to go back to the blue board :-)

I think that it will work fine if you combine the thread and getParent methods. You construct the panel in the applet thread, so you have no problem accessing that. In the AWT thread, you have already constructed everything, so you can use the getParent method.

It's a bit of extra work to implement both, but as I said before, these two together cover most bases.

Wow. What a lot of work for what seems like it would be such a simple thing. Shows, I guess, that's it's not so simple after all. My strongest recomendation is that, whatever you wind up doing, you hide it all in a single method (and/or a single object passed around) because you definately don't want this cluttering up your application logic.

-- Michael Chermside

Ugh, such a long discussion...

Did anyone suggested separate classloader for each applet? (I guess it won't work for 1.1 JVM though).

Starting applet class does nothing except of creating worker class through newly created URLClassLoader. It's 1.2 specific class and I doubt that 1.1 security will allow use of class loader, if security is not an issue, it's still possible to create custom class loader similar to URLClassloader. Each applet instance will get own set of classes and static variables.

Regards,
Igor Bazarny

You cant replace the classloader in applets, not even in a signed applet.
(it may somehow work in explorer, but never in netscape).

when exactly do you create your objects and when exactly do you need configuration information ?

Excellent idea.

mcherm, you have some points waiting for you for your participation.

just to make it clear :
the Excellent idea was aimed at ET3D :-)

I'm happy that I can offer some help to such Java experts as yourself and Sasha. You seem to be working on something pretty interesting. This and Sasha's question about resolution were pretty thought provoking, compared to other questions on this site.

I really wasnt very optimistic when I posted the question..
I was pretty sure I cant be solved in a clean way.
Glad I was wrong.