-
Enhancement
-
Resolution: Fixed
-
P4
-
1.3.0
-
beta3
-
x86
-
windows_nt
Name: skT45625 Date: 10/27/2000
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
Developers could use some documentation about the lifespan of static variables
used by applets run in the plug-in. This is especially important in knowing how
to use static variables reliably and correctly. Often applet developers use
static variables to maintain information when an applet is re-instantiated.
The lifecycle of a static variable is clearly tied to the classloader that
loaded its class. But when is the classloader dumped? The Sun VM spec is very
general here:
"2.17.8 Unloading of Classes and Interfaces
A class or interface may be unloaded if and only if its class loader is
unreachable. The bootstrap class loader is always reachable; as a result,
system classes may never be unloaded."
Here are some more specific questions:
1) When does a static class variable go out of scope? Under what conditions is
the plugin classloader (sun.plugin.security.PluginClassLoader) dumped?
2) How does the cache of plugin classloaders work? In BugParade, 4364107 says
that "The classloader cache size is too big, we have changed it to 10 instead
of 100, so applet won't run out of memory that easy". What determines whether
an existing classloader is reused and when a new one is created? What are the
implications of the classloader cache on the use of static variables?
3) What, if any, is the relationship between a plug-in applet's codebase (or
URL) and the classloader used? Is the reuse of a classloader dependent on the
applet's codebase (or URL)?
(Review ID: 109602)
======================================================================