JDK-6697772 : JDK 6u10 installer doesn't install public JRE if JRE 6u5 was installed on that machine
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,windows,windows_nt,windows_xp generic,windows,windows_nt,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-05-05
  • Updated: 2010-09-08
  • Resolved: 2008-07-11
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 b27Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Description
There is a public JRE component inside JDK installer, I did the following test on one machine:

1. Install JRE 6u5 on that machine.
2. Install JDK 6u10 on the same machine, the public JRE component didn't show up during installation, it is thinking the machine already has the latest JRE 6u10, which isn't correct.

I tested on both 32bit and 64bit OS, with 32bit JDK and 64bit JDK, the same issue has been found. It is important to fix this issue in 64bit OS because it will stop to install 64bit JRE when you have a 32bit 6u5 JRE installed on user's machine.

Comments
SUGGESTED FIX Changed JDK MSI to check for SOFTWARE\JavaSoft\Java Runtime Environment\[JDK_VERSION], JavaHome registry entry instead of [MAJOR].[MINOR] for JREINSTALLED. Use AWK_RegLocator_Type so x64 JDK sets JREINSTALLED based on x64 registry. NewSignature2 was renamed to SameVersionJREInstalledSignature so AWK_RegLocator_Type can modify the correct entry for x64. Changes to sdk\Makefile to validate on windows-amd64: run Wi64bitValidation.vbs to modify the Validation table after InstallShield creates the MSI test cases: http://oklahoma.east.sun.com/deployment/www/tests/1.6.0_10/testcase_6697772.txt : 1. For windows-i586 JDK a. (regression test) With no JRE installed Install 6u10 JDK Verify Public JRE is offered to be installed and installed when left selected. b. With 6u5 JRE installed Install 6u10 JDK Verify Public JRE is offered to be installed and installed when left selected. c. Install 6u10 JRE Install 6u10 JDK Verify Public JRE is not offered to be installed, and 6u10 JRE still installed 2. For windows-amd64 JDK on x64 Windows OS. a. (regression test) With no JRE installed Install 6u10 JDK Verify Public JRE is offered to be installed and installed when left selected. b. With 6u5 x64 JRE installed Install 6u10 JDK Verify Public JRE is offered to be installed and installed when left selected. c. Install 6u10 x64 JRE Install 6u10 x64 JDK Verify Public JRE is not offered to be installed, and 6u10 JRE still installed d. Install 6u10 32-bit JRE Install 6u10 x64 JDK Verify Public JRE is offered to be installed and installed when left selected.
11-06-2008

EVALUATION The fix would involve changing the Condition.idt table for the sdk, as well as the RegLocator for NewSignature2. Something like this: <<NewSignature2 2 SOFTWARE\JavaSoft\Java Runtime Environment\[MAJOR].[MINO R] JavaHome 2^M >>NewSignature2 2 SOFTWARE\JavaSoft\Java Runtime Environment\[FULLVERSION] JavaHome 2^M
06-06-2008

EVALUATION this has nothing to do with 64 bit install. install of JDK is not offering JRE install
05-06-2008

EVALUATION This is correct behavior. As of 6u10, our stance is that if they already have a public JRE of the same family (6), then we do not offer a public JRE. It was getting to be too much of a headache to deal with all of the reinstall behavior in those cases, and with little reward. We depend on auto-update to keep their public JRE up-to-date. If the true 64-bit installer is asking for a reinstall of the public JRE, then that's the bug.
16-05-2008