Miguel wrote:
> Kent wrote: > > >>(except for static final >>variables, which are of course okay). > > > Correct > I'm not so sure. Why are these not a problem? I'm pretty sure it was a final static array def that led to the problems I fixed in isosurface. Maybe it wasn't final.... <http://svn.sourceforge.net/viewcvs.cgi/jmol/branches/bob200603/Jmol/src/org/jmol/viewer/Isosurface.java?r1=5206&r2=5207> Maybe it was just the nonfinal ones that were causing the problem. I'm certain that the following was for SURE a problem, but I think it was probably more than that. static Vector3f[] pixelVertexVectors = new Vector3f[4]; Why would final make a difference here -- the pointer to the object may be final, but the contents of the object are changeable by individual threads. You really think that final static Matrix3f matXyzToPlane = new Matrix3f(); can't cause a problem when a new thread loads it? Bob > 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. sure. That makes good sense. > Bob -- Robert M. Hanson, [EMAIL PROTECTED], 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:[EMAIL PROTECTED] http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
