I would presume that Sun Java 6 update 10 is installed on your client's computers. If not, you could probably force the applet to run in a JVM whose version is atleast 6u10. I'm unsure about the error that will be thrown, or the error message displayed if the required version of the JVM is not found.
Apart from that, there is no guarantee that a separate JVM instance will be created when the separate_jvm parameter is specified in an APPLET tag.
The only guarantee is that the applet will run in its own JVM separated from other applets. If a JVM is already available and if no applet has been loaded in that JVM, then it is possible for the JVM to load the applet in the already initialized JVM instance.
For the Sun Java 6 u10 release notes, the following salient points are worth reading:
Here is a rough set of guidelines from the 6u10 release notes, for the sharing and creation of new JVM instances:
- If the command-line arguments used to start a preexisting JVM instance are a superset of the requested arguments, the preexisting JVM instance will be used.
- If a JVM instance is launched for the "default" set of command-line arguments (i.e., those specified in the Java Control Panel, with no java_arguments specified), then this JVM instance will never be used to launch any applet that has even one command-line argument specified via java_arguments.
- -Xmx is handled specially: if a preexisting JVM instance was started with for example -Xmx256m via java_arguments, and a new applet requests -Xmx128m, then new applet will very likely be run in the preexisting JVM instance. In other words, -Xmx specifications are matched with a greater-than-or-equal test.
The best bet therefore is to provide java_arguments in the applet tag, such that there is a very high probability of launching the applet in a separate JVM.