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.
                                     

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.
                                     

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)
                                     

EVALUATION

The number 6282093 should be 6282039, right?