FULL PRODUCT VERSION :
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Any OS running Webstart 1.6. Reproduced specifically Windows XP.

EXTRA RELEVANT SYSTEM CONFIGURATION :
This issue is applicable to any Windows machine using Webstart.

A DESCRIPTION OF THE PROBLEM :
Webstart 1.5 and earlier versions supported classpath ordering.

Jar files could be ordered by placing the newer jars ahead of the older one in the jnlp descriptor file.

Webstart 1.6 does not respect this ordering. There appears to be no way to order the classpath.

Java forum discussion here:
http://forum.java.sun.com/thread.jspa?threadID=5161715

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Below is an example jnlp skeleton to show the issue.

The jars could be ordered by using the resource and jar tags.

<jnlp> Example skeleton
  <resources>
    <jar href="newercode.jar" />
  </resources>

  <resources>
    <jar href="oldercode.jar" />
  </resources>
</jnlp>



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The classpath for the application launch should have the jars this in the order.

classpath=newcode.jar;oldercode.jar
ACTUAL -
The order is determined by the cache code in Webstart 1.6, the load order follows the caching logic, which I have not figured out yet.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Due to undetermined load order, MethodNotFoundException were being throw.

Any kind of exception could be thrown, as old code was being loaded before the latest code.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Rolling all the new and old code a new jar.

This is not practical due to version control issues and defect tracking for our customers.

Also, third party libraries have to be patch sometimes, we cannot recreate the vendor jars due to signing issues and again version control.

See the linked Java Forum thread for a discussion of why we need this functionality.