1

Because I develop Java applications in both 64 bit and 32 bit environments, I maintain both Java VM's in my development environment. A JNLP application I developed must run in a 32 bit environment because it calls a dll which requires a 32 bit environment.

Most of the time the JNLP does seem to "know" that it needs to run in the 32 bit environment but I suspect that I've just been lucky. When I upgraded my 64 bit Java to version 10, it caused the JNLP to fail because the JNLP tried to run in the 64 bit environment. When I restored the 64 bit environment to version 1.8 (the same version as the 32 bit environment, the application started running in the 32 bit environment again.

But how does it know to do this? Is there some property of JNLP applications which causes it to default to the 32 bit environment if the Java versions are the same?

Is there a way to guarantee that the JNLP will run in a 32 bit environment by setting something in the environment or specifying a particular JRE library when I do my build?

user2864740
  • 60,010
  • 15
  • 145
  • 220
Elliott
  • 5,523
  • 10
  • 48
  • 87

2 Answers2

1

Is there a way to guarantee that the JNLP will run in a 32 bit environment by setting something in the environment or specifying a particular JRE library when I do my build?

The short answer is apparently: No.

The following explains the the way that you specify the version to be used in a JNLP spec file:

You should be able to force selection of a 32bit JVM by only specifying the resources for a 32 bit architecture; e.g.

  <resources os="Linux" arch="x86">
    <nativelib href="lwjgl-x86-linux.jar"/>
  </resources>
  <resources os="Linux" arch="i386">
    <nativelib href="lwjgl-x86-linux.jar"/>
  </resources>

(For development / testing purposes, you could use a development JNLP file that leaves out the 64 bit resources ...)

However, as you have discovered, this does not help if the JNLP client is going to use the 64 bit JVM if it is available ... and then complain that the 64 bit resources are missing.

It may be possible to modify the way that the JNLP client / launcher makes its choice. However, that would be dependent on the launcher you are using; e.g. it may depending on the Java plugin you are using, and whether you can configure it to use a specific JRE.

And it turns out that there are known bugs / inconsistencies in the way that some JNLP clients decide whether to use 32 or 64 bit JREs.

However, JNLP and JavaWebstart are deprecated in Java 9 onwards, so you should probably be looking for an alternative. Especially if you / your clients don't intend to pay for Oracle Java commercial support.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Unfortunately, it is now throwing an error. I entered the following: – Elliott Apr 28 '18 at 03:51
  • – Elliott Apr 28 '18 at 03:52
  • And I get this error: No application resources are specifed for this platform. Please, contact the vendor of the applcation to make sure that this is a supported platform – Elliott Apr 28 '18 at 03:53
  • OK. So that doesn't cause the JNLP client to choose a specific JRE. In that case, the only choice is configuring your platform's JNLP client ... if that is possible. (Which actually makes sense. It is a potential security issue if a JNLP spec file can cause different JREs to be used ... without the user knowing.) – Stephen C Apr 28 '18 at 04:01
  • Apparently, this is a known bug. At least as late at 1.7 (although I am running 1.8). https://bugs.openjdk.java.net/browse/JDK-8029922 – Elliott Apr 28 '18 at 04:10
  • What finally worked for me was, running in a Windows environment, I right clicked on the JNLP and used the Open with option. Then I chose the javaws under the 32 bit java environment. That caused the application to open with a 32 bit java. – Elliott Apr 28 '18 at 04:12
0

After extensive experimenting, what I discovered was the following.

First, modifying the Resources element in the XML of the JNLP installation to accept a specific architecture (e.g. x86) does not seem to work and in fact throws an error.

Second, installing any jvm greater than 1.8 will result in the JNLP using that JVM. Since Oracle does not support 32 bit JVM's beyond 1.8, this means the JNLP application will run in a 64 bit environment Apparently, the JNLP will run on the latest version available. At least Java's behavior on my machine seems to suggest this.

Third, as documented here, bugs.openjdk.java.net/browse/JDK-8029922, if you are running both a 32 bit and a 64 bit jvm on the same machine, then the order in which you install these jvms matters. To ensure that the JNLP application picks up the 32 bit jvm, you need to install that version of java second. In other words, the JNLP apparantly runs the last version of java installed regardless of the bitness of the jvm, UNLESS the JVM installed first, is a later version of java. Then, the later release is the one in which the JNLP runs.

Since Oracle no longer seems to be supporting 32 bit versions of java after version 1.8, the implication is that if you need your JNLP to run in a 32 bit environment, you must install java versions 1.8 OR EARLIER for this to happen.

Since Webstart and JNLP are deprecated, as the question answerer above suggests, it is time to consider a different technology for deploying java applications other than Webstart.

Elliott
  • 5,523
  • 10
  • 48
  • 87