> Miguel, Egon, other Java pros, I need your help: > > Is it possible that when you use static variables in an applet then, > when there are multiple applets on a page all loading at the same > time, they share each other's variables?
Yes, the definition of a static variable is that all instances share the same variable. Put another way, the variable is associated with the class, not with the instance. The JVM only loads a class once, and it is shared across multiple threads within the same 'process' and across multiple 'processes'. > -- i.e. TRASH each other's > variables? The *purpose* of static class variables is to provide a mechanism for different instance in potentially different threads to *communicate* with each other in a coordinated (synchronized) fashion. If the usage of the variables is not coordinated then they will TRASH each other. > I've got a page with 5 isosurfaces, one in each of 5 applets, and each > time I load it at least one of them is totally trashed -- but trashed > in a DIFFERENT way seemingly randomly each time I load. OK > I realize now it is because I assigned "static" to arrays of objects > that really aren't static. Then that is your problem. Good job in identifying this. Developers should not use 'static' variables unless they understand the implications ... and the implications can be complicated in a multi-threaded world. > If the answer to this question is YES, then could this explain some of > the odd null pointer errors that have arisen in the colix/normix area > recently? > > For example, I see in Colix.java: > > private static int[] argbs = new int[128]; > > Now, maybe the "private" takes care of this, but if some other applet > had assigned values to "argbs", wouldn't this then cause a problem? The argbs variable is 'static' by design. In cases where there are multiple instances of the applet, I thought that there was value if having them share the same argb->colix mapping. Write access to the 'argbs' array is funnelled through a 'synchronized' procedure to ensure that only one thread at a time can update the 'argbs' array. I am not saying that there are no bugs in the Colix code ... but it was made 'static' by design and the code has essentially remained unchanged for 3 years ... so it is not the first place that I would look. > I'm reminded of the day I saw a button control on one page rotate the > model on another..... Yes, I agree that this sounds like a related issue. Multiple applets with the same name being active at the same time. > Is this an issue we should look into? As with all bugs, it is best to avoid them in the first place. Bugs that change behavior because of improper synchronization between threads/processes fall under the general heading of 'race conditions'. These bugs are generally the worst to track down. Multi-threading stuff is very complicated. Many have complained that the threading support built into Java makes inter-thread communication too easy ... and therefore too easy to introduce race conditions. Java provides low-level synchronization primitives, but one usually must build their own infrastructure to support robust thread-synchronized access to data structures. Developers should not introduce static member variables without I used some static+synchronized access to some variables in a couple of places in the code ... like Colix. I made a conscious decision to do so because I thought that the associated data structures could be safely shared across threads/processes. Miguel _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
