JDK-8055448 : Provide a way to specify JRE data model requirements in JNLP file
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u23
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: x86
  • Submitted: 2011-06-22
  • Updated: 2017-05-19
  • Resolved: 2015-07-20
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 b76Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8182548 :  
Currently, there is no way for a Web Start application to specify that it is only compatible with a 32-bit JRE, or that it requires a 64-bit JRE.  If a user has installed both 32-bit and 64-bit versions of JavaSE at the same release level, the JRE that will actually be used when launching a Web Start application is indeterminate.  The application might launch with a 32-bit data model, or a 64-bit data model.

The Web Start developer guide describes a "-d32" option for vm-args, but as discussed in bug 6907802, the feature is only supported on Solaris and even if it were supported on Windows, it would still fall short because it will only use a 32 bit JRE "if available".  What is needed is a way to require a 32 bit JRE, even if one is not currently installed.  It may also be necessary for some applications to require a 64-bit JRE even if one is not currently installed.

Web Start applications that depend on JNI libraries need to specify which data model should be used if the appropriate JNI libraries are only available in one data model.  This is primarily a concern for older applications that depend on 32-bit libraries and need to require a 32-bit JRE.

It may also be the case that some applications have design requirements that depend on a 64-bit data model and would not be able to function in a 32-bit environment.  These applications need a way to specify that they should be launched in a 64-bit JRE.

When both 32-bit and 64-bit JRE's are installed, if the JNLP file specifies only one data model or a preferred data model, that is the data model that is used.  If the JNLP file does not indicate a requirement or a preference, then one data model or the other should be the consistent default choice.
Currently, the behavior is inconsistent (it appears that it might depend on which JRE was installed last).  Your application may launch on the 32-bit JRE, or the 64-bit JRE, and there is no way to control this.

---------- BEGIN SOURCE ----------
N/A.  This RFE is pointing out a gap in the JNLP spec.
---------- END SOURCE ----------

1) Refrain from installing a 64-bit JRE if you have an application that requires a 32-bit JRE.  Refrain from installing a 32-bit JRE if you have an application that requires a 64-bit JRE.

2) It appears that whichever JRE was installed last might influence this behavior, but to the extent that this is true, that mode of control is not sufficient to accommodate the needs of various applications that require one data model or the other.

No plans to address in 6 or 7, hence the WNF labels

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

The basic change is that when cross-architecture jres are supported by JDK-8003984, then JREDesc items in resources blocks with arch attributes will not be filtered out (when arch does not match). Instead the arch attribute will be added to the JREDesc , and the selection mechanism is modified to select the appropriate jre. This allows you to specify order of jres you want, of either architecture: <resources arch="x86_64"> <java version="1.8"/> </resources> <resources arch="x86"> <java version="1.9"/> </resources> The above would mean first preference is 64 bit JDK8, if not available, 32 bit JDK9.

group of tests at: http://oklahoma.us.oracle.com/www/tests/1.9.0/32-64/ crucible review at: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-1206

after JDK-8003984 we need to investigate if this preference works properly. currently only resources matching the currently running jre are considered, but this should be different for JREDesc items, we should consider any <java> or <j2se> element in a resources block matching either architecture if relaunching cross architecture is supported.

currently, resources can be made data model specific using the arch attribute, though not without making them processor specific also, however there are problems when specifying java element as in: <resource arch="x86"> <java version="1.7+"/> <jar href="jarforx86.jar"/> </resources> The above , when run on x86 arch will indicate preference to use java version 1.7+ and will include jarforx86.jar, however when run on x64 arch, it will not recognize that any preference for 32 bit has been made and will try to run with whatever other resources are left. The deployment code is run in one arch or the other and has no knowledge that the other may be available (either in this jre or other versions). It would be better if it were aware of java versions of the other arch, and had the ability to relaunch into the "correct" one. I am not sure if a syntax change is necessary to indicate either preference or requirement for one arch over the other. we could recognize the following as a preference for x86 arch: <resources arch="x86"/> <java version="1.0+"/> </resources> <resources> <java version="1.0+"/> </resources that is, listing the requested java versions with their arch in order, chose the best available jre matching the first request, if that is different arch, relaunch into that arch.