Kent wrote: > I haven't done any actual development on Jmol, but I've done a bunch > of work on another applet, so I'll put in my two cents worth... > > Yes, this may well be a problem. We definitely saw this with the applet > I work on; in fact, as I recall even multiple applets on *separate* > pages clobbered each others' static variables.
Correct. The Sun Java Plug-in will load a class only once ... and it will be shared across all processes. This is by design. I have always feared that this might also introduce subtle problems because of two different versions of the same class name coming from different servers might be shared ... and the first one to arrive gets loaded. (A few years ago Konqueror on Linux was not using the Sun Java Plug-in. Therefore, behavior was different because each applet received its own java process with its own address space. I don't know their status today.) > We went through a big > "get rid of all static variables" process Many projects have had to do this. I am not sure, but I strongly suspect that the Java source-code verification tools allow one to flag use of 'static' variables because they are a potential source of race conditions. > (except for static final > variables, which are of course okay). Correct > One important note, though: the way browsers deal with applets varies > greatly between different browsers, even within the same family (e.g., > Mozilla vs. Netscape). True ... in line with my comment above about Konqueror. And Sun's position has changed over time (although most of those changes were in the mid-late 1990's after the initial introduction and with field experience.) >> 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? 'private' restricts visibility to the variable, but does not change behavior. But the two *are* related and you frequently see 'private static' for the following reason: If you want to explicitly have shared access to data through 'static' member variables then it is important that you know all of the places that are accessing the data. Therefore, you want to consolidate all of your references in the same place. By restricting the scope to 'private' you ensure that no one outside your compilation unit (that source file) has access to your 'private static' variable. > I don't think "private" made any difference with the problems we had. > This was two or three years ago, though. As I recall, the Java spec > really gives browsers a lot of leeway in how they run applets. True > It should be pretty simple to test if different applets are actually > trashing each others' static variables. It can frequently be very difficult to identify these problems ... best to avoid them. Miguel _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
