JDK-8003984 : Allow relaunch between 32 / 64 bit versions in Java Web Start when you have latest versions of both
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u81,7u55,8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_vista
  • CPU: other
  • Submitted: 2012-11-26
  • Updated: 2017-01-07
  • Resolved: 2015-07-18
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 8 JDK 9
8u102Fixed 9 b76Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Given is a 64-bit Windows box, where both 64-bit Java SE 7 Update 9 and 
32-bit Java SE 6 Update 37 are installed.

Furthermore, there is a Java Web Start application that requires to run on Java SE 6.
This requirement is explicitly given in the jnlp file:

% grep j2se jacc.jnlp
      <j2se version="1.6" max-heap-size="512m"/>


The following behaviour is strictly reproducible:
Java Web Start of JRE 7 is used, if this JRE 7 was installed most recently.
Java Web Start of JRE 6 is used, if this JRE 6 was installed most recently.

The behaviour was introduced with Java SE 7 Update 6.
Java SE 7 Update 5 was still fine in this respect:
regardless of the installation order, Java Web Start of JRE 1.6.0 was used.

Comments
No plans to address for JDK 6 or 7, hence WNF.
08-04-2016

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

This RFE will be used for the main set of changes to allow relaunching javaws between dual architecture versions when deployment code is available for both. (on platforms that support duel architectures, such as 64 bit windows ) The JCP will also be modified to always show both sets of available JRES , with an additional column to show archeticture of the jre. When the deployment code is only installed in one architecture, both will be shown in JCP, but only those matching the architecture of the deployment code will be used. (such as when 32 and 64 bit versions of JDK8 are installed on windows, but only 32 bit version of JDK9 is installed).
13-07-2015

The fix in progress is to consider "all compatible jres, both 64 and 32 bit" only when both 32 bit and 64 bit version of the latest jre is installed. This is because we cannot mix 32 bit deployment code with 64 bit jre code (or vise versa) and for security reasons we must only run deployment code from the latests installed jre. When only one of 32 bit or 64 bit versions of the latest installed jre are installed, we will continue the ond behavior, of only considering the installed jres of the same architecture.
09-07-2015

" The behaviour was introduced with Java SE 7 Update 6. Java SE 7 Update 5 was still fine in this respect: regardless of the installation order, Java Web Start of JRE 1.6.0 was used." This is misleading - actually the only difference between releases is which javaws is registered. The current behavior (and always has been) is whichever javaws is run (32 or 64 bit) that run will only consider the jre's of the same architecture. If you launch 32 bit javaws - only 32 bit jres will be considered, and if you launch 64 bit javaws, only 64 bit java versions are considered. What we need is full 32/64 bit interoperability, on platforms (such as windows) that support both.
24-06-2015

received feedback from Thomas
25-08-2014

Is this still an issue for the latest 6u and 7u ? Pending feedback from Thomas.
21-08-2014

I was able to reproduce similar problem when trying to relaunch jre 7 -> jre 6. For the case jre 8 -> jre 7 - it works fine. So I guess it needs to be reassigned to Sustaining team.
23-05-2014

Workaround: Re-install Java SE 6 JRE over existing installation will fix the problem.
26-11-2012