United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7067322 Redirection of registry keys not happening correctly with old plugin
JDK-7067322 : Redirection of registry keys not happening correctly with old plugin

Details
Type:
Bug
Submit Date:
2011-07-14
Status:
Closed
Updated Date:
2012-04-09
Project Name:
JDK
Resolved Date:
2011-10-12
Component:
deploy
OS:
windows
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
7u2 (b08)

Related Reports
Backport:
Backport:

Sub Tasks

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



Hardware and Software, Engineered to Work Together