JDK-8010636 : User responsibilities are not updated with all clsid's with jre 6u32 and higher
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u32
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-03-22
  • Updated: 2014-11-17
  • Resolved: 2013-03-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 JDK 7 JDK 8
6u51Fixed 7u40Fixed 8Fixed
Description
SHORT SUMMARY:
On Windows XP under a non-admin user account the HKCU registry branch
misses static version CLSIDs for all Java versions older than the
installed update release. The HKLM registry branch doesn't have these
entries too. Because of this, when an applet uses a static version
CLSID to specify the minimum required Java version, the user is
prompted to download an update release (requested by the applet) that
may be actually older than the one already installed.

INDICATORS:
No static version CLSIDs for old Java versions in both the HKLM and
HKCU registry branches.
A prompt to download a Java update release older than the one already
installed.

TRIGGERS:
- Windows NT family OS older than Windows Vista.
- Non-admin user account.
- An applet uses a static version CLSID to identify the requested
  Java version.
- The installed Java is newer that the one requested by the applet.

KNOWN WORKAROUND:
- Update the registry with the missed entries manually.

PRESENT SINCE:
6u32 b04, 7u2 b08.

HOW TO VERIFY:
A manual run of an applet using a static version CLSID.

REGRESSION:
Yes, this is a regression of JDK-7029567 + JDK-7067322.
Comments
The problem happens because when the Java plugin is loaded by IE on Windows XP under a non-admin user account, the required static versioning registry entries are missed from both the HKCU and HKLM branches. Earlier these entries were updated in the HKCU branch every time IE loaded the Java plugin. Recently the performance fix JDK-7029567 + JDK-7067322 reduced the set of updated entries to those corresponding to the current Java version only. The CLSID registry entries are updated in two cases: - The Java installer is registering the Java plugin in the system. It is always run under an administrator user account, and in case of Windows Vista or later OS, in the high integrity mode. It always registers the full set of CLSID registry entries. - IE loads the Java plugin library. This is how the registry entries appear in the HKCU branch for a non-admin user account. After the performance fix, only a limited set of registry entries is updated, and this exposes the issue. The code responsible for updating the CLSID registry entries is located in src/plugin/win32/ssv_common/SSVCommonUtils.cpp The original design (before Windows Vista) was that for non-multi-user Windows platform (for example, Windows 98), the code puts entries into the HKLM branch. Otherwise, it puts them into the HKCU branch. Windows Vista introduced a security restriction described here: http://msdn.microsoft.com/en-us/library/bb756926.aspx "If the integrity level of a process is higher than Medium, the COM runtime ignores per-user COM configuration and accesses only per-machine COM configuration." So the code had to be changed to its current state, and, besides the HKCU branch, the HKLM branch is also updated for Windows Vista and later OSes if the process is running in the high integrity mode. This is why the problem is not seen with Windows Vista and later OSes - the required entries are taken from the HKLM branch. The fix is to put the entries into the HKLM branch (besides the HKCU branch) for Windows versions earlier than Windows Vista, too. Conceptually, Java is installed and Java plugins are registered per-machine, not per-user. So, a logical solution would be to always add the static versioning entries to the HKLM branch only. I didn't follow this way because it may create some compatibility issues. The HKCU entries, if present, take precedence over the HKLM entries. It may create some undesired effects when several Java versions are installed on the same machine.
22-03-2013