P5
A DESCRIPTION OF THE REQUEST :
http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet_deployment.html#JAVA_ARGUMENTS
This states the following:
When JVM command-line arguments are specified, it is likely that the new plug-in will need to launch another JVM instance in order to satisfy them. In other words, it is unlikely that a preexisting JVM instance will have been started with the correct set of command-line arguments to satisfy the request. The rules for exactly when a new JVM instance is launched to start a given applet are deliberately left unspecified, as this functionality is brand new in the 6u10 release and may need to change in subsequent releases. Here is a rough set of guidelines for the sharing and creation of new JVM instances:
That is not good enough. We have 4 Applets on one page, and they need to communicate with each other. Otherwise they are broken. If a new JVM is started for any of the Applets, they cannot communicate with the others via AppletContext getApplet etc.
JUSTIFICATION :
A clear specification for Applet communications is required.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
getAppletContext() and getApplet() work just like they did in the old plug-in - e.g. for Applets that are on the same page and loaded from the same server.
Our Applets depend on this behavior.
ACTUAL -
getAppletContext and getApplet randomly don't work when the JVM decides to not load the Applets in the same JVM.
There is no clear specification for this ("The rules for exactly when a new JVM instance is launched to start a given applet are deliberately left unspecified").
Ideally, there would be a way to force Applets to use one specific named JVM. Something that is explicitly ruled out on the documentation.
It seems that the authors of the documentation simply forgot about Applet-Applet communication when they decided that the plug-in knows best when to start new JVMs and when not. Alternatively, getAppletContext could be made to work across JVM boundaries. There are many different ways to fix this, really, but the current situation is unacceptable.
CUSTOMER SUBMITTED WORKAROUND :
Don't define java_argument parameters and hope for the best. Works mostly.
http://java.sun.com/javase/6/docs/technotes/guides/jweb/applet/applet_deployment.html#JAVA_ARGUMENTS
This states the following:
When JVM command-line arguments are specified, it is likely that the new plug-in will need to launch another JVM instance in order to satisfy them. In other words, it is unlikely that a preexisting JVM instance will have been started with the correct set of command-line arguments to satisfy the request. The rules for exactly when a new JVM instance is launched to start a given applet are deliberately left unspecified, as this functionality is brand new in the 6u10 release and may need to change in subsequent releases. Here is a rough set of guidelines for the sharing and creation of new JVM instances:
That is not good enough. We have 4 Applets on one page, and they need to communicate with each other. Otherwise they are broken. If a new JVM is started for any of the Applets, they cannot communicate with the others via AppletContext getApplet etc.
JUSTIFICATION :
A clear specification for Applet communications is required.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
getAppletContext() and getApplet() work just like they did in the old plug-in - e.g. for Applets that are on the same page and loaded from the same server.
Our Applets depend on this behavior.
ACTUAL -
getAppletContext and getApplet randomly don't work when the JVM decides to not load the Applets in the same JVM.
There is no clear specification for this ("The rules for exactly when a new JVM instance is launched to start a given applet are deliberately left unspecified").
Ideally, there would be a way to force Applets to use one specific named JVM. Something that is explicitly ruled out on the documentation.
It seems that the authors of the documentation simply forgot about Applet-Applet communication when they decided that the plug-in knows best when to start new JVMs and when not. Alternatively, getAppletContext could be made to work across JVM boundaries. There are many different ways to fix this, really, but the current situation is unacceptable.
CUSTOMER SUBMITTED WORKAROUND :
Don't define java_argument parameters and hope for the best. Works mostly.
- relates to
-
JDK-7169864 Multiple applets in a frameset causes a separate JVM to be created
-
- Closed
-