FULL PRODUCT VERSION :
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Windows 7 Service Pack 1

A DESCRIPTION OF THE PROBLEM :
When I launch a new version of our webstart application, the old jnlp is used to launch the application.

REGRESSION. Last worked in version 7u51

ADDITIONAL REGRESSION INFORMATION:
Picked up _JAVA_OPTIONS: -Xmx2048M
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Launch a webstart application
Deploy a new version of the application with a different jnlp. For instance use a newer version of a jar as a dependency in the jnlp.
Download the new jnlp from the server.
Open the jnlp and check that it is in fact the newer version.
Double click the jnlp file to launch it.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The newer application should launch correctly
ACTUAL -
An error dialog comes up with file not found exception because the cached jnlp (instead of the new jnlp) launches and is looking for the old referenced jar instead of the new jar. The jnlp in the "Launch File" tab of the error dialog does not matched the jnlp that was launched.



ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.io.FileNotFoundException: http://www.iarchives.com/test/lib/test-2.0.259.jar
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.access$200(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$9.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessController.doPrivileged(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
This is not an issue that can be replicated with a simple source code test case. A simple application needs to be created and web start application set up in order to test this.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Clearing the Java cache solves this issue.