JDK-6613373 : Plugin2: Applet fails to load in case invalid run time params are supplied
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u5
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2007-10-05
  • Updated: 2010-09-08
  • Resolved: 2008-01-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b11Fixed
Related Reports
Relates :  
JDK-6647070 - JSObject reference counting problem
Relates :  
JDK-6646674 - Add mechanism for ignoring unrecognized command-line arguments with standard Java launcher
Relates :  
JDK-6609036 - Add more heartbeats to the system
Description
Negative scenario: Applets fails to load if invalid runtime parametres are specified. Either a native error pop-up is there or VM dies silently.
Try supplying invalid params like -Xtint -Xmc512m and load , try to load any applet.
Old Plug-in simply ignored the invalid value and load an applet using default runtime parameters.
Comments
EVALUATION This fix introduced a regression in the browser-side heartbeat code added in 6609036 where cold start situations could cause the attached JVM to be abruptly terminated. This regression is described and fixed in 6647070.
04-01-2008
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6613373.2 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6613373/
03-01-2008
EVALUATION The old Java Plug-In set the ignoreUnrecognized flag in the JavaVMInitArgs to true, causing any illegal command-line arguments to be silently ignored. The new Java Plug-In repurposes the standard Java launcher, which sets ignoreUnrecognized to false when it creates the JVM. Any illegal arguments specified therefore cause the launcher to abort. It would be useful to be able to set ignoreUnrecognized to true with the standard launcher, and RFE 6646674 has been filed about this. In the interim, to emulate the old behavior as closely as reasonably possible, we now detect whether the target JVM started successfully. A successful launch is detected by a message sent from the target JVM back to the browser. If the launch was unsuccessful, we attempt to re-launch the target JVM and any applets it should contain after clearing out all of the user-specified command-line arguments. It is not feasible to isolate exactly which command-line argument caused the JVM to fail to launch. Both the JVMParameters matching code and the capturing of the JVMParameters by the JVMInstance were adjusted to avoid excessive re-launches. To the outside world (i.e., the browser side), the browser thinks the JVM instance was launched with the requested arguments; only the JVMInstance knows that the command-line arguments were cleared out. The HeartbeatThread in the JVMInstance is now created only when the target JVM launches successfully, and the logic was simplified. On the Windows platform we now no longer use the javaw.exe launcher but instead use the java.exe launcher. javaw.exe pops up a message box if illegal command-line arguments were specified which is undesirable. It turns out that the java.lang.Process code already specifies CREATE_NO_WINDOW during the underlying CreateProcess call, so no unwanted DOS console is shown. The JP2Launcher used on Vista was modified to do the same.
03-01-2008