JDK-6368613 : REG:java is not working after mustang upgrade/downgrage from/to 1.3.1_X/1.4.2_X/1.5.0_X on windows
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows,windows_xp
  • CPU: x86
  • Submitted: 2006-01-04
  • Updated: 2010-05-09
  • Resolved: 2006-02-04
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
6 b71Fixed
Related Reports
Duplicate :  
JDK-6372216 - java.exe still fails because it cannot find msvcr71.dll (winxp vmware)
Relates :  
JDK-6376717 - java/javaw (-version) exec chain can be optimized
Relates :  
JDK-6282039 - java.exe/javaw.exe need to work with vc7
Relates :  
JDK-6376718 - javaws exec chain can be optimized
Description
This bug now is reproducible in the latest Mustang beta build 59e also.

java is not working after mustang upgrade/downgrage from/to 1.3.1_X/1.4.2_X/1.5.0_X on windows.
Steps to reproduce:
- install mustang (jre1.6.0) build 65 (promoted)
- make sure "java -version" is working
- install tiger update (jre1.5.0_06) (latest promoted)
- try "java -version", it is not working 
- uninstall jre1.5.0_06 
- try "java -version" again, it is not working
and if you in step 5 uninstall jre1.6.0, java will be removed totaly from windows system dir (but we still have jre1.5 on the machine)
It is a regression. Everything works fine with jre1.6.0_build62
------------------------------------------------------------------------------
I did further testing and it is looks worse then it was from the beginning:

This is how our Mustang behave now:

1) Upgrade from 1.3.1_X to Mustang

- on clean machine (no jre), install 1.3.1_X version
- upgrade it to Mustang (you can use any build starting from build 64 (63 working fine))
- remove 1.3.1_X version (uninstall 1.3.1_X)
- try java ("Command not found") (this is another bug, I think not related to Joe's changes)
- from IE, try "Sun Java Console" - it is not registered (this is another bug, I think not related to Joe's changes)
- now, if you try to execute javaws error coming:
Initial Java Virtual Machine Launcher
Failing reading value of registry key:Software\JavaSoft\Java Runtime Environment\CurrentVersion

Same scenario working fine with build 63

2) Upgrade from 1.4.2_X to Mustang

- on clean machine (no jre), install 1.4.2_X version
- upgrade it to Mustang (you can use any build starting from build 65 (64 working fine))
- remove 1.4.2_X version (uninstall 1.4.2_X)
- now try to execute java, it is not responding at all (javaws working fine)

Same scenario working fine with build 64

3) Upgrade from 1.5.0_X to Mustang

- on clean machine (no jre), install 1.5.0_X version
- upgrade it to Mustang (you can use any build starting from build 65 (64 working fine))
- remove 1.5.0_X version (uninstall 1.5.0_X)
- now try to execute java, it is not responding at all (javaws working fine)

Same scenario working fine with build 64
Comments
EVALUATION The number 6282093 should be 6282039, right?
25-01-2006
SUGGESTED FIX Files changed: make/java/Makefile changed ordering of module build (launcher must now preceed javac) make/java/launcher/Makefile changes to the way static linking is specified (mis-merge correction) make/java/launcher/Launcher.gmk make/java/launcher/launcher/Makefile make/java/launcher/launcherw/Makefile changes to the way static linking is specified (mis-merge correction) and install changes make/java/main/java/Makefile make/java/main/javaw/Makefile _impl added to name src/windows/bin/launcher.c changed to look in $ORIGIN directory first for *_impl executables make/javaws/Makefile Statically linked src/plugin/win32/regutils/RegInstall.cpp Install names expected by older installers (revert code to previous state)
25-01-2006
SUGGESTED FIX 6282039 introduced a "mini-launcher" free of dependencies on mscvr71.dll and mscvp71.dll. Three copies of this mini-launcher were installed into the "system32" directory as the moral equivalent of symbolic links to the real launchers for java, javaw and javaws. A better solution for javaws is simply to statically link it (an option overlooked in the implementation of 6282039). That option is implemented here. Although this increases the size of javaws, the increase is less than a dynamic javaws plus a copy of the mini-launcher, so this is actually a "win" compaired to the alternatives. Static linking of the java/javaw executables was not considered viable because JNI allows libraries we have no control over into the address space, creating the possibility of mixing static and dynamic linking which is clearly warned against by Microsoft. (Note, that this possibility still exists, but by not changing our model we allow bug-for-bug compatibility with previous releases.) Hence, the executables for java and javaw were renamed (_impl added) and copies of the mini-launcher were installed into $JREHOME/bin as java and javaw. The mini-launcher was modified to look in its $ORIGIN directory first for copies of the real launcher and then examine the registry for the default (as it always did). The net result is that the thing called "java" in $JREHOME/bin is the same binary we want copied into the "system32" directory. Note, that in the case of the SDK, two copies of java_impl.exe are present; on in $JAVAHOME/bin and another in $JAVAHOME/jre/bin. It would be possible to remove one of these, but that was not done. The reasons are: 1) Maintains $JAVAHOME/bin as an exact superset of $JAVAHOME/jre/bin 2) Follows the Windows convention of always looking for dependencies of an object in the same directory as that object. 3) Will allow much simpler implementations of optimizations to this mechansm (see 6376717 and 6376718) The only real advantage to one copy of the real launcher would be a decrease in the download size of the SDK. The download size of the JRE (the one we care about) wouldn't be changed.
25-01-2006
EVALUATION This defect was introduced by CR 6282093. An additional constraint on the solution (unknown at the time) is that installers for previous release have hardwired knowledge of what binaries to copy into the Windows "system32" directory, in order to make another VM the default. This happens even when the older VM being installed is not the default (which is poor logic, if not a bug). However, it also needs to happen when the default is being removed, so the problem exists anyway. Therefore, the additional constraint on the solution for 6282093 is that the *exact* set of binaries copied into the "system32" directory can not be altered. This restriction should be removed from future installers, but many moons will need to pass before the restriction can be lifted. See suggested fix.
25-01-2006