JDK-6625757 : Native code for deploy needed in basically all situations
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-11-05
  • Updated: 2010-09-08
  • Resolved: 2008-01-31
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 b08Fixed
Description
With certain changes to the JVMParameters class that require the calling of the Config class on the client (attached) JVM side (namely the querying of whether the JVM is secure), it becomes apparent that deploy.dll from the JRE containing the new Java Plug-In is needed in basically all situations. PluginMain needs to load the deploy shared object using specialized code because the normal loading mechanism will load it from the JRE it is running on top of, which causes a mismatch between the Java code and native code for these classes.
Stack trace of failure when currently running on top of 5.0 family:
java.lang.UnsatisfiedLinkError: canDownloadJRE
  at com.sun.deploy.config.WinConfig.canDownloadJRE(Native Method)
  at com.sun.deploy.config.WinConfig.canAutoDownloadJRE(Unknown Source)
  at com.sun.deploy.config.Config.refreshProps(Unknown Source)
  at com.sun.deploy.config.Config.initialize(Unknown Source)
  at com.sun.deploy.config.Config.<clinit>(Unknown Source)
  at sun.plugin2.jvm.JVMParameters.isSecure(Unknown Source)
  at sun.plugin2.main.client.PluginMain.mainLoop(Unknown Source)
  at sun.plugin2.main.client.PluginMain.run(Unknown Source)
  at sun.plugin2.main.client.PluginMain.main(Unknown Source)

Note that this is an inadvertent regression caused by the fix for 6607516, but the underlying problem could have been uncovered at any time.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6625757.0
06-11-2007
EVALUATION A recent change caused deploy.dll / libdeploy.so to be pulled in from JRE on top of which the new Java Plug-In was running. It must be pulled in from the JRE containing the new Java Plug-In to prevent a mismatch of the deployment Java classes and native code. Added code to load deploy.dll / libdeploy.so in all situations. Tested manually with simple MJRE test and verified that applet running on top of 5.0 release train ran instead of failing during startup with UnsatisfiedLinkError. No regression test at this time, although an automated one will eventually be produced as a consequence of the addition of multiple JRE support in the new plug-in.
06-11-2007