FULL PRODUCT VERSION :
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

AND

java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) Client VM (build 25.102-b14, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

EXTRA RELEVANT SYSTEM CONFIGURATION :
C:\Program Files\Java\jre1.8.0_102 (8u102 64bit)
AND
C:\Program Files (x86)\Java\jre1.8.0_102 (8u102 32bit)
installed

A DESCRIPTION OF THE PROBLEM :
Running applications with 32/64 bit dependend code is broken in java 8u102 when you have installed both (32 and 64 bit) runtimes.
I think this bugfixes broke it:
- https://bugs.openjdk.java.net/browse/JDK-8055448
- https://bugs.openjdk.java.net/browse/JDK-8003984

We have a swt application which need special jar for every platform and arch. This is a simplified version of our jnlp:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://ghlx02.guh-local.de/jws/protilo" href="protilo.jnlp">
<information>
...
</information>
<security>
<all-permissions/>
</security>

<resources>
<java version="1.8+"/>
<jar href="protilo.jar" />
</resources>
<resources os="Windows" arch="x86">
     <jar href="win32/swt.jar"/>
</resources>
<resources os="Windows" arch="amd64">
     <jar href="win64/swt.jar"/>
</resources>
<resources os="Linux" arch="i386">
     <jar href="linux32/swt.jar"/>
</resources>
<resources os="Linux" arch="amd64">
     <jar href="linux64/swt.jar"/>
</resources>

<application-desc main-class="de.guhsoft.protilo.Main"/>
</jnlp>

It seems that java 8u102 does not filter for arch in resources (descripted here: https://bugs.openjdk.java.net/browse/JDK-8055448?focusedCommentId=13823297&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13823297).

If i look into the java viewer (of both jres) and display the jnlp file (right click on application, "show jnlp file") is se the following:

> ...
> <jar href="http://ghlx02.guh-local.de/jws/protilo/win32/swt.jar" download="eager" main="false"/>
> <jar href="http://ghlx02.guh-local.de/jws/protilo/win64/swt.jar" download="eager" main="false"/>
> ...

(which is wrong, it should the 32bit one for 32bit jre and the 64bit one for 64bit jre)

If i do that on the previous releases (alos 32 and 64 bit vm installed), this is shown:

32bit JRE:
> ...
> <jar href="http://ghlx02.guh-local.de/jws/protilo/win32/swt.jar" download="eager" main="false"/>
> ...

64bit JRE:
> ...
> <jar href="http://ghlx02.guh-local.de/jws/protilo/win64/swt.jar" download="eager" main="false"/>
> ...

When i run this, it fails:

> "C:\Program Files (x86)\Java\jre1.8.0_102\bin\javaws.exe" http://ghlx02.guh-local.de/jws/protilo/protilo.jnlp

When i run this, it works:

> "C:\Program Files\Java\jre1.8.0_102\bin\javaws.exe" http://ghlx02.guh-local.de/jws/protilo/protilo.jnlp

This is the exception we get (it loads the wrong library):

java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on
64-bit JVM
    at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
    at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
    at org.eclipse.swt.internal.C.<clinit>(Unknown Source)
    at org.eclipse.swt.widgets.Display.<clinit>(Unknown Source)
    at de.guhsoft.protilo.Main.<init>(Main.java:66)
    at de.guhsoft.protilo.Main.main(Main.java:59)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.sun.javaws.Launcher.executeApplication(Unknown Source)
    at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
    at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
    at com.sun.javaws.Launcher.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

REGRESSION. Last worked in version 8u92

ADDITIONAL REGRESSION INFORMATION:
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

AND

java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) Client VM (build 25.92-b14, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use a jnlp with 32 and 64 bit resources like this:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp spec="1.0+" codebase="http://ghlx02.guh-local.de/jws/protilo" href="protilo.jnlp">
<information>
...
</information>
<security>
<all-permissions/>
</security>

<resources>
<java version="1.8+"/>
<jar href="protilo.jar" />
</resources>
<resources os="Windows" arch="x86">
     <jar href="win32/swt.jar"/>
</resources>
<resources os="Windows" arch="amd64">
     <jar href="win64/swt.jar"/>
</resources>
<resources os="Linux" arch="i386">
     <jar href="linux32/swt.jar"/>
</resources>
<resources os="Linux" arch="amd64">
     <jar href="linux64/swt.jar"/>
</resources>

<application-desc main-class="de.guhsoft.protilo.Main"/>
</jnlp>

Install both 32 and 64 bit java 8u102 jres/jdks

Run

> "C:\Program Files (x86)\Java\jre1.8.0_102\bin\javaws.exe" http://ghlx02.guh-local.de/jws/protilo/protilo.jnlp

and

> "C:\Program Files\Java\jre1.8.0_102\bin\javaws.exe" http://ghlx02.guh-local.de/jws/protilo/protilo.jnlp

first will fail, second works.

if you change the resource order in your jnlp, the opposite will happen...

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
both should work
ACTUAL -
exception cause wrong library will be loaded

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on
64-bit JVM
    at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
    at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
    at org.eclipse.swt.internal.C.<clinit>(Unknown Source)
    at org.eclipse.swt.widgets.Display.<clinit>(Unknown Source)
    at de.guhsoft.protilo.Main.<init>(Main.java:66)
    at de.guhsoft.protilo.Main.main(Main.java:59)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.sun.javaws.Launcher.executeApplication(Unknown Source)
    at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
    at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
    at com.sun.javaws.Launcher.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
no workaround found

SUPPORT :
YES