FULL PRODUCT VERSION :
1.6.0_12-b04

ADDITIONAL OS VERSION INFORMATION :
MS windows XP Version 5.1.2600

A DESCRIPTION OF THE PROBLEM :
1. Install Java Runtime 6 Update 12.
2. Install a java application
3. Launch Java Cache Viewer and install desktop shortcut for that application
4. Launch that application by clicking the short-cut on desktop.

Expected result: the java application starts to load

Actual results:
Error: Could not load file/URL specified: C:\Documents and Settings\username\Application
Data\Sun\Java\Deployment\cache\6.0\28\70b584dc-49b0bb30

But this file does exist:
C:\Documents and Settings\username\Application
Data\Sun\Java\Deployment\cache\6.0\28\70b584dc-49b0bb30.idx

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Install Java Runtime 6 Update 12.
2. Install a java application
3. Launch Java Cache Viewer and install desktop shortcut for that application
4. Launch that application by clicking the short-cut on desktop.

Expected result: the java application starts to load

Actual results:
Error: Could not load file/URL specified: C:\Documents and Settings\username\Application
Data\Sun\Java\Deployment\cache\6.0\28\70b584dc-49b0bb30

But this file does exist:
C:\Documents and Settings\username\Application
Data\Sun\Java\Deployment\cache\6.0\28\70b584dc-49b0bb30.idx

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected result: the java application starts to load
ACTUAL -
Actual results:
Error: Could not load file/URL specified: C:\Documents and Settings\username\Application
Data\Sun\Java\Deployment\cache\6.0\28\70b584dc-49b0bb30


ERROR MESSAGES/STACK TRACES THAT OCCUR :
CouldNotLoadArgumentException[ Could not load file/URL specified: C:\Documents
and Settings\username\Application Data\Sun\Java\Deployment\cache\6.0\28\70b584dc-49b0bb30]
	at com.sun.javaws.Main.launchApp(Unknown Source)
	at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
	at com.sun.javaws.Main$1.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)


REPRODUCIBILITY :
This bug can be reproduced always.

Release Regression From : 6u11
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
Posted Date : 2009-02-24 09:01:48.0

N/A

Problem:  Customer (cobaltgroup.com) reported problem in 6u12.

Customer's JNLP application cannot be started from desktop shortcut.

Customer's JNLP file has max-heap-size set to a customzied value.  Also, customer server is always return 200 (for whatever reason), so everytime we launch, cached JNLP is always updated.

In 6u12, when we launch from shortcut, a relaunch is triggered in java code (Problem 1), because native code did not set the max-heap-size when launching java.  And when we re-launch in java code, we relaunch with the original cached JNLP, which doesn't exists anymore, because we updated the cached JNLP. (Problem 2).  This caused the desktop shortcut launch problem seen by the customer.

Fix:

For Problem 1, when we launch from desktop shortcut, -localfile is used.  This cause copyTmp to be false, and therefore bypassed the copy of temp JNLP file in native code, but it also bypassed the parsing of the JNLP file all together.  That's why native code didn't launch with the max-heap-size args.

If -localfile is used, we should by pass the copy of the temp JNLP file, but we still need the native code to parse the cached JNLP file.

For problem 2, after we updated and got the final launchDesc JNLP file, and after we removed the temp JNLP (if necessary), we should update args[0], in case we need to re-launch.
Posted Date : 2009-02-25 06:32:26.0

I think we've stumbled upon the same problem, although we can reproduce it with one user (jre 1.6.0_13) by doing this:
1. Install Java Runtime 6 Update 12.
2. Install and run a java webstart application (which makes a shortcut)
3. Upgrade the jnlp on the server
4. Launch that application by clicking the short-cut on desktop.

Hopefull 1.6.0_14 fixes it for us too.

Seeing the same thing with our app, which has both custom max-heap-size, as well as a JNLP file which is auto-generated on each request with a new mod-time and potentially updated parameters.

Users found the problem for us in u13; hope 14 is out soon and works!

I just updated to b05 of update 14 and found that while this may be fixed another severe bug has been introduced. 

Web start now uses the cached JNLP even if the JNLP has changed on the server. In our case, the cached JNLP referenced jars which no longer exist on the server.... thus web start attempts to retrieve an updated version of the non-existent jar and fails to load the app.

The net result is that the jnlp reference must be deleted via the javaws -viewer and the jnlp must be requested again to refresh the app.

Hi, 
I can confirm also that this bug is solved in 6.14.

I can confirm also that "Web start now uses the cached JNLP even if the JNLP has changed on the server". Meaning that java cannot detect if there are any changes in the jnlp. 

Hope this gets fixed before the final release.