JDK-6709583 : when 64-bit public JRE already installed, JDK installer will uninstall it but not reinstall it
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 6u10
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-06-02
  • Updated: 2010-04-04
  • Resolved: 2008-06-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
6u10Resolved
Related Reports
Duplicate :  
Description
Steps to reproduce:

1. Install 64-bit 6u10 JRE
2. Launch 64-bit 6u10 JDK installer, it will still offer the public JRE (it shouldn't)
3. Keep the public JRE feature selected, and proceed with install.
4. JDK installer will say that you already have a JRE installed, would you like to reinstall.
5. Select YES.
6. JDK installer will uninstall JRE, but not reinstall it.

Expected behavior:  Actually, as of 6u10, the public JRE should not be offered if they already have it.  So step 2 is the bug.
See also CR 6712020: jdk 64 bit Installer doesn't offer JRE if 32 bit JRE is already installed in the system.
Same cause, different test case.
See also 6697772.  Re-assigning this CR to Chris as it should be addressed with his fix.

Comments
EVALUATION There is a condition in the JDK installer for "PublicjreFeature" that is not being checked correctly. the condition uses (JREINSTALLED <> "0") and if you look at the JREINSTALLED property, it is set with the signature, "NewSignature2." In the RegLocator table, NewSignature2 points to the public key containing JavaHome. The issue is that the Type of the signature is NOT SET TO 18 for 64bit...it's set to 2. The Makefiles perform some AWK commands which set these values in the tables at build-time. So the fix will involve the following: 1. Rename the signature from "NewSignature2" to something that makes more sense and won't collide with other signatures generated by the wizard in the JRE installer (see #2, below). Propose a new name of "JREInstalled_Signature." The signature name change will need to be done in both RegLocator.idt and AppSearch.idt for the SDK install ws. 2. Add the newly named signature above to the common def file (install/make/common/Defs-windows.gmk) in the statement that sets "AWK_RegLocator_Type." 3. Add AWK_RegLocator_Type statement to SDK installer Makefile, the same way it exists in the JRE installer Makefile, in the "setup_installer_files" target, (if $ARCH == 64). Doing these 3 steps should allow the JDK installer to accurately read the registry and set JREINSTALLED so that the public JRE is not offered in this scenario. I have tested the fix in-place on a 64bit Vista host (hidri.east) and it appears to work. No way to test the Makefile changes except to generate a webrev and run a build. In progress...
02-06-2008

EVALUATION FYI, this is only with the 64-bit installer. I've verified that the 32-bit installer works correctly.
02-06-2008