JDK-8149497 : cannot relaunch to alternate architecture
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u102,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2016-02-09
  • Updated: 2017-07-31
  • Resolved: 2016-02-12
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.
8u102Fixed 9 b110Fixed
Related Reports
Relates :  
Relates :  
The implementation of JDK-8003984 allows a jnlp application to relaunch from one architecture to another if the os supports it (currently windows only)
however there are two circumstances where this does not work:
1.) if the two versions are the same, web start will see that it is already running a jre that matches version of the required jre and so will not relaunch.
This can be easily addressed in JREMatcher.isVersionMatch(ld, jre) by requiring match also match architecture)
2.) if using a platform version specification, and the target jre (of the other arch) is not FCS. 
We currently will not match a platform version request to a non FCS version unless it is the exact same jre we are running javaws from (even if it is the other arch of the same version).
This restriction is obsolete and should just be removed. 

two further related problems:
3.) when getting new installed versions (windows) by recognizing that they have been added to the registry, the version (taken from the registry) is the no-dash version (1.8.0_76, not 1.8.0_76-internal) , when taken from java.version property of the running version, it is the full 1.8.0_76-internal.  This has always been the case, and has not previously caused problems, but now with JDK-8133495, if you newly install both 32 and 64 arch of latest release, and run either one, the check for the existence of the other arch of the same version will fail, since current arch will be full version, and alternate arch will be no-dot version. - just need to compare no-dot version to fix this.
4.) for versions previous to "9" , registration of a version included adding both "1.8" and "1.8.0_76" to registry.  For JDK9, only "9" is registered.  As a result, and to prevent duplicates, we have code in JREInfo.updateJREs() to reject versions who do not have a dot (".") char beyond the second char.  this code clearly cannot apply to "9" so will be further conditionalized to registered versions starting with "1".

Verified with jre9-b178 on win10/x64

crucible review for backport to 8u: https://java.se.oracle.com/code/cru/CR-JDK8UDEV-321

including a fix for issue 5: 5.) javaws no longer updates deployment.properties with registered JRES. (it uses the registered jres, just never updates deployment.properties to reflect them.) since 32-64 fix, updateJREs in JREInfo is called from JREInfo.initialize() preventing later call from ClientConfig.updateJREs() from seeing that anything had changed.

above not quite true. There are several reasons javaws from 8u76 cannot relaunch into a later version (jre-9). For one thing, using javaws.jar and deploy.jar from 8u76 in 9 jre would get NoSuchClass exceptions on any sun.misc classes used in 8 but not existing in JDK9 (such as sun.misc.BASE64Encoder). Deploy code in JDK8 or 8U supports only running with JDK5, JDK6, JDK7, or JDK8. we have checks to prevent trying to run with earlier releases but no checks to prevent trying to run with later releases.

to test: 1.) install both 32 and 64 bit versions of target jre. 2.) remove all jre entries in deployment.properties 3.) run <path to 32 bit jre>/javaws http://oklahoma.us.oracle.com/www/tests/1.9.0/32-64/hello9-64.jnlp 4.) remove all jre entries in deployment.properties again 5.) run <path to 64 bit jre>/javaws http://oklahoma.us.oracle.com/www/tests/1.9.0/32-64/hello9-32.jnlp should be able to see that simple app is run in the selected arch (look at first line in console output to confirm which jre is running note for 8u, the corresponding tests exist, hello8-32.jnlp and hello8-64.jnlp. when all 4 versions are installed (assuming these fixes in both 9 and 8u installed) any of the 4 versions of javaws should be able to run all 4 of the tests and get the right jre running.

Crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-1768