JNLP does not provide you a way to define class path. It provides you a way to define what will be available to your application.
Fact that application jars are added to the class path is implementation detail.
E.g. in JDK8 application will be modularized and there will be no explicit class path notion unless it is compatibility mode.
If your web application depends on overloading resources provided by other jar it is fragile design.
As for loading generally speaking following is happened:
a) set of resources needed to run application is built from JNLP files
b) these resources are partitioned into groups based on priority - progress jars, regular eager jars, lazy jars
c) progress jars are loaded concurrently
d) regular jars are loaded concurrently (up to 5 jars at the same time i believe)
e) all jars are added to classpath. Current rule is to add progress jars first, then regular jars, then lazy jars (and this is current implementation details too).
The idea is that jars that are needed earlier should go in front to avoid pause in application trying to load class that is available
(as classpath lookups are sequential attempt to lookup in the not yet loaded class will block until jar is loaded)
In reality it is a bit more complicated as signed and unsigned resources are loaded by different class loaders and this also has impact of effective jar lookup order.