xxxxx@xxxxx   2002-07-31

If multiple jre, say 1.3.1fcs and 1.4.0_02, exists in a system, JaWS prefers 1.3.1fcs.


OS	: WindowsNT, Windows XPpro
JDK	: JDK 1.4.0_02rebundle and FCS

Steps To Reproduce Dirty Installation of J2SDK1.4.0_02 rebundle:
1. Install J2SDK 1.3.1 (FCS)
2. Install J2SDK 1.4.0_02rebundle/1.4.0 FCS over existing J2SDK 1.3.1 (FCS)
3. Start JaWS, it works
4. Uninstall J2SDK 1.3.1 (FCS)
5. JaWS will not work

Results:

When running a Java Web Start demo after uninstallation 1.3.1, Java Web Start looks for the previously installed version of JRE, 1.3.1, and hence cannot run the demo. This should not have been the case as Web Start was installed along with JRE 1.4.0_02 and should have given preference to it's own JRE (1.4.0_02). Upon looking at the javaws.cfg file. It is evident that this is the case.

This is also experienced when testing with JDK 1.4 FCS.

Error Message below is produced:

- Bad Installation. Error invoking Java VM (SysExec)
  C:\Program Files\ xxxxx \JRE\1.3.1\bin\javaw\exe
  


  xxxxx@xxxxx   2002-10-30

I feel it necessary to point out that the removal of a JRE shows us the problem, but is not the problem I was referring to when I logged the bug. 

Upon further investigation, i have found that when both JREs (1.3.1 installed before 1.4 say) are on the system, and a JAWS demo is ran, the Java version used to run the demo, shown on the Java Console indicates the older JRE, 1.3.1. This is further evident in the javaws.cfg file where it clearly indicates where -

	javaws.cfg.jre.0. entries point to the older JRE version, 1.3.1

and the newer JRE version given a lower "preference" eg javaws.cfg.jre.2.

The problem occurs during the installer program of 1.4.0. While installing JAWS it only detects 1.3.1 as a suitable JRE. I think 1.4 should be detected during the install, and hence JAWS would then use 1.4 ?

Removal of the older JRE version therefore results in the failure to run the JAWS demo.

We can tweak javaws.cfg to make it work with 1.4.0_02 by manually editing. The entries look like below
	
	javaws.cfg.jre.0.location=http\://java.sun.com/products/autodl/j2se
	javaws.cfg.jre.0.product=1.4.0_02
	javaws.cfg.jre.0.platform=1.4
        javaws.cfg.jre.0.path=c\:\\ProgramFiles\\Java\\j2se1.4.0_02\\bin\\javaw.exe
	
Also we observed that it works if it is jre.0 and for other values (jre.1 or jre.2) it does not work.

If there is multiple jre exists, say 1.3.1fcs and 1.4.0_02, javaws always prefers 1.3.1fcs (i.e older jre).
In this situation customers are not able to take advantage of newer jre.

	
	

Investigate for Mantis.

  xxxxx@xxxxx   2002-08-05

Java web start doen not "prefer" an older version of a jre to a newer one.
the jnlp files for each application specify persicesly the "preference".

We intend, in mantis, to address the problem whenin uninstalling a jre that is 
listed in the javaws.cfg file is not reflected in that javaws.cfg file.

  xxxxx@xxxxx   2002-08-14

in mantis, if a jre listed in javaws.cfg file is removed, we will detect it and remove it from javaws.cfg as well.


  xxxxx@xxxxx   2002-10-29

The remaing part of this bug is a dupe of 4773110.
The native code in javaws, given a choice of multiple jre's that match the apps 
specification, was taking the first one in the list, instead of the latest
version.
This is fixed in mantis.
  xxxxx@xxxxx   2002-11-06