JDK-8147627 : 64 bit only app may have problems when initially launched with 32 bit javaws
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86_64
  • Submitted: 2016-01-19
  • Updated: 2017-06-02
  • Resolved: 2017-06-02
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 9Fixed
Related Reports
Relates :  
Sub Tasks
JDK-8179702 :  
Description
When launching a javaws application in JDK9, you now have capability of describing the preference that the app launch in 64 bit jre.  Iif the app is incapable of running in 32 bit jre, it may be that 32 bit javaws will throw exceptions before getting to the relaunch code where it would relauinch from 32 to 64 bit jre.

For example, if an app has no resources except under 64 bit specific resource block:
   <resources arch="x86_64">
      <java version="1.7+"  href="http://java.sun.com/products/autodl/j2se"/>
      <jar href="hello.jar" />
   </resources>
and it is started in 32 bit javaws and jre, then it should relaunch to 64 bit javaws and jre (if available) and run.

However, before relaunching, javaws will check if the main jar has manifest entries referencing the main class, and (since there is yet no main jar) throw exception that the main class is null.
Other exceptions may have to be postponed till user is given the opportunity to relaunch to 64 bit jre, related to not having any resources for the current jre.

This same problem should be demonstrable with just versions.
If app (for example) is required to run with jre 1.7*, it can express resources nested within jre 1.7* java element, and need not supply valid resources for 1.8 or 1.9.  In such case, there should be no error until and unless it is found 1.7* is not available, or user decides to "run with the latest version"
In fact in such cases it would be beter not just not give user the option of "running with the latest"

Comments
Was working the release note subtask and updated the top issue instead.
02-06-2017

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

implementing option 2 above. Crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-1733
27-01-2016

it turns out XMLFormat adds all resources in embedded resource block even if resource block is within java block of non matching version. This means if you have different jars for java 7 and java 8, they will both be downloaded, and their signature checked before running. (Though I think only the proper one will be loaded by the class loader, need to check). Although this is wrong, it has been this way for 15 years without anyone reporting any ill effects. Now this is not the case for resource block with non matching os or arch (only the resources from blocks where the os and arch match are included.) Now this means there are two ways we could fix this problem. 1.) Re-arrange the code in Launcher to allow a LaunchDesc with no resources to pass thru at least until we are past point of relaunch (then it can be an error as it is now). 2.) Act like we do for non-matching java version in XMLFormat, allowing non-matching but compatible arch values, so both 32 bit and 64 bit resources would be downloaded and security checked in the primary VM before relaunch. #1 is a little more complex and has the disadvantage of the possibility of signed jnlp file in a 64 bit only jar file which is not downloaded by the first VM. The jnlp file could have insecure properties which would not be used in the relaunch, and we prevent relaunching twice. #2 has the disadvantage of downloading and running security check on resources that will never be used (as we do now for java version case).
22-01-2016

interesting ... The behavior with http://oklahoma.us.oracle.com/www/tests/8147627/test7.jnlp, which has: <resources> <java version="1.7*" href="http://java.sun.com/products/autodl/j2se"> <resources> <jar href="hello.jar" /> </resources> </java> </resources> Is about what we would want, in that with JDK9 only installed, it gets to the "1.7* not available, run with latest ?" dialog, then fails with message saying null main class. Final message is not optimal (would prefer "no resources specified for this jre", but at least it gets thru to point where we would relaunch to jre 7 if available. Is worse for the 32/64 bit case at : http://oklahoma.us.oracle.com/www/tests/1.9.0/8147627/test64.jnlp which has: <resources arch="x86_64"> <java version="1.7+" href="http://java.sun.com/products/autodl/j2se"/> <jar href="hello.jar" /> </resources> here it says no main class while running 32 bit jre before getting far enough to relaunch to 64 bit jre.
19-01-2016