FULL PRODUCT VERSION :
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)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
MacOS X 10.11.4 (15E65)
Linux r2d2 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
Layout on the Server

Dachsweb.jar
lib.signed <- signed libs in her
lib <- there were the unsigned libs, wich shouldn't be used

see workaround

A DESCRIPTION OF THE PROBLEM :
The apache-webserver access.log indicates, that the Webstart-classloader tries to load the classes from the Manifest.MF inside the main-jar after it loaded the jars from the
resources-Tag

<resources>
        <jar href="Dachsweb.jar" main="true"/>
        <jar href="lib.signed/Dachsweb-common.jar"/>
...
</resources>

Manifest.mf from Dachsweb.jar
Class-Path: lib/Dachsweb-common.jar ....

This should not be the case




REGRESSION. Last worked in version 8u77

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

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Start
http://commserver.senertec.com/dachsweb/Dachsweb.jnlp

with 1.8.0_92 or 1.8.0_91
-> Console shows, that it tries to load lib.signed/lib/Dachsweb-common.jar which doesn't exist
Note! ..this would be a failure, if we wouldn't have installed a workaround

with 1.8.0_77
it just loads the jars specified by the webstart-file

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Apache Access-Log like in 1.8.0_77

x.x.x.x - - [17/Apr/2016:08:19:35 +0200] "GET /dachsweb/Dachsweb.jar HTTP/1.1" 304 191 "-" "JNLP/1.7.0 javaws/11.77.2.03 (<internal>) Java/1.8.0_77"
..
x.x.x.x - - [17/Apr/2016:08:19:35 +0200] "GET /dachsweb/lib.signed/Dachsweb-common.jar HTTP/1.1" 304 190 "-" "JNLP/1.7.0 javaws/11.77.2.03 (<internal>) Java/1.8.0_77"
..
<no wrong entries>

ACTUAL -
Apache Access-Log 1.8.0_91 (it doesn't matter if 91 or 92)

x.x.x.x - - [20/Apr/2016:09:16:18 +0200] "GET /dachsweb/Dachsweb.jar HTTP/1.1" 304 190 "-" "JNLP/1.7.0 javaws/11.91.2.14 (<internal>) Java/1.8.0_91"
..
x.x.x.x - - [20/Apr/2016:09:16:18 +0200] "GET /dachsweb/lib.signed/Dachsweb-common.jar HTTP/1.1" 304 190 "-" "JNLP/1.7.0 javaws/11.91.2.14 (<internal>) Java/1.8.0_91"
... no the wrong entries (not lib/lib is not in the MANIFEST.MF)
x.x.x.x - - [20/Apr/2016:09:16:34 +0200] "GET /dachsweb/lib/Dachsweb-common.jar HTTP/1.1" 200 1494120 "-" "Java/1.8.0_91"
x.x.x.x - - [20/Apr/2016:09:16:39 +0200] "GET /dachsweb/lib/lib/Dachsweb-common.jar HTTP/1.1" 404 563 "-" "Java/1.8.0_91"

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Without workaround you get Cert-errors and java.lang.NoClassDefFoundError

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
We had to change the dir-layout on the server
$ mv lib lib.unsigned
$ ln -s lib.signed lib

so that it works again

It gets loaded twice nonetheless .