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"