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".