JDK-7067322 : Redirection of registry keys not happening correctly with old plugin
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: deploy
  • Sub-Component: plugin
  • Priority: P3
  • Affected Version: 7
  • OS: windows
  • CPU: generic
  • Submit Date: 2011-07-14
  • Updated Date: 2012-04-09
  • Resolved Date: 2011-10-12
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 Availabitlity Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8
6u32Fixed 7u2 b08Fixed 8Fixed
Description
SYNOPSIS
--------
Redirection of registry keys not happening correctly with old plugin

OPERATING SYSTEM
----------------  
Windows

FULL JDK VERSION
----------------
JDK 7 (tested with b147)
(Problem introduced between b138 and b143)

DESCRIPTION from LICENSEE
-------------------------
During installation, 131, 142, 150 and 160 (30 keys created for each update) are created as CAFEEFAC under HKCU (0 to 30). For example:

HKEY_CURRENT_USER\Software\Classes\CLSID{CAFEEFAC-0016-0000-0029-ABCDEFFEDCBA}
HKEY_CURRENT_USER\Software\Classes\CLSID{CAFEEFAC-0016-0000-0029-ABCDEFFEDCBB}
HKEY_CURRENT_USER\Software\Classes\CLSID{CAFEEFAC-0016-0000-0029-ABCDEFFEDCBC}

and here we mention the key as jp2iexp.dll as default.

When we uncheck the next gen plugin in Control Panel, all of these keys should get redirected to ssv.dll, which is not happening.

A new function, RedirectSelectedStaticVersionKeysImpl(), was introduced in place of RedirectStaticVersionKeysImpl() in /deploy/src/plugin/win32/ssv_common/SSVCommonUtils.cpp. In this new function, we try to get the installed jre list and redirect only those associated CLSID's.  I don't think this is right because this will lead to inconsistent behaviour as mentioned above.

I suppose the rationale behind creating all those CLSID's when the JREs aren't installed was that even if a users testcase is pointing to older CLSID it should run with latest JRE. So I don't know why we try to get the installed JREs and redirect only those keys. I'm not sure if this understanding is correct.

REPRODUCTION INSTRUCTIONS
-------------------------
1. Install JDK 7 build
2. Associate old plugin with IE
3. Launch the below applet in IE

Expected result:
  It should launch with old plugin

Observed result:
  It tries to launch it with old plugin, while new plugin is actually associated. I see it launches sometimes and fails sometimes.

TESTCASE
--------
jversion.html
-------------
<title>Java -version</title>
<hr>
<OBJECT classid="clsid:CAFEEFAC-0013-0001-0000-ABCDEFFEDCBA"
WIDTH = 400 HEIGHT = 30  codebase=".">
<PARAM NAME = CODE VALUE = "jversion.class" >
<PARAM NAME="type" VALUE="application/x-java-applet;jpi-version=1.3.1">
<PARAM NAME="scriptable" VALUE="false">
</OBJECT>
<hr>

jversion.java
-------------
import java.awt.*;
import java.applet.*;

public class jversion extends Applet {
        public void paint(Graphics g) {
                g.drawString("Java RunTime Environment is: "+System.getProperty("java.vendor")+" "+System.getProperty("java.version"), 20, 20);
        }
}

Comments
EVALUATION Problem is due to an optimization fix to improve IE browser startup time. With the fix, we always call RedirectSelectedStaticVersionKeys from ssvagent. For switching between old and new java plugin via the Java Control Panel, we need to redirect all static version keys. Fix is to introduce another ssvagent command line arg ("-fullreg"). The new arg. will be passed to ssvagent for the case when the user switches between old and new java plugin via the Java Control Panel. In ssvagent, if the "-fromjcp" arg is there, it'll call RedirectAllStaticVersionKeys.
2011-09-19