JDK-7067947 : plugin dll fail when using from FX runtime due to calling into UNICODE deploy.dll
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7-client
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • CPU: x86
  • Submitted: 2011-07-16
  • Updated: 2011-08-06
  • Resolved: 2011-08-06
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 7
7-clientResolved
Related Reports
Duplicate :  
JDK-7068024 - Partial plugin is broken
Description
JRE 7-client build + FX runtime

browser applets cannot load at all
Comments
EVALUATION this is fixed by 7068024 Created, P2 java_deploym/general Partial plugin is broken
06-08-2011
EVALUATION Found the problem and a fix/workaround. Problem is when running with partial deploy from FX runtime, plugin dll needs to call into deploy dll to get the jvm home from registry, in order to get path to jvm.dll. BOOL GetCurrentJavaHomeFromRegistry(LPTSTR lpszJavaHome); But plugin dll is ASCII for now; and deploy.dll is now UNICODE. So we are mixing the lpszJavaHome with char and wchar. This is the first time we use UNICODE deploy bits in FX deploy scrum - that's why we see it now. To workaround this, we can hardcode in plugin code to call the function with wchar, and convert it to char after: http://javaweb.sfbay.sun.com/~ngthomas/webrevs/rt15116/webrev/ This makes deploy from FX runtime works again. The right fix of course is to make plugin dlls UNICODE too; but that would be more complex. Should we do this for now or try make plugin dlls UNICODE too ?
16-07-2011