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 :
 customer  Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
When the jnlp file is updated at the server, JWS fails to start the application the first time. "Unable to launch the application" message is shown instead. This happens with only some jnlp file contents, not all. At least <property> tags and os attributes in resources seem to have some impact. The effect of the content seems quite illogical, so there might be other tags and attributes effecting too.

The symptoms are exactly like in 6446676, which is reported to be fixed in mustang(b94).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- download http://java.sun.com/products/javawebstart/apps/draw.jar to your web server to some directory
- save the following as draw.jnlp in the same directory:
-------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?>

<jnlp spec="0.2 1.0"
      codebase="http://server/path/"
      href="draw.jnlp">
   <information>
      <title>Draw 4 App</title>
      <vendor>Sun Microsystems, Inc.</vendor>
      <homepage href="http://java.sun.com/products/javawebstart/demos.html"/>
      <description>A minimalist drawing application along the lines of Illustrator</description>
      <description kind="short">Draw Demo Short Description</description>
      <icon href="images/draw.jpg"/>
      <offline-allowed/>
   </information>
   <resources os="Win">
      <property name="sun.java2d.noddraw" value="false"/>
      <j2se version="1.3+" href="http://java.sun.com/products/autodl/j2se"/>
      <j2se version="1.3+"/>
      <jar href="draw.jar" main="true" download="eager"/>
   </resources>
   <application-desc main-class="Draw"/>
</jnlp>
-------------------------------------------------------------------------
(note: change the codebase in this example to correct one)
- open draw.jnlp with browser -> draw app starts
- run command touch draw.jnlp in the server
- open draw.jnlp with browser

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Draw application starts
ACTUAL -
Unable to start application appears.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Details for "Unable to launch the application" message:
Exception:
CouldNotLoadArgumentException[ Could not load file/URL specified: D:\Documents and Settings\aa015037\Application Data\Sun\Java\Deployment\cache\6.0\59\1c52e23b-1084115d]
	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)

Wrapped Exception:
java.io.FileNotFoundException: D:\Documents and Settings\aa015037\Application Data\Sun\Java\Deployment\cache\6.0\59\1c52e23b-1084115d (The system cannot find the file specified)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(Unknown Source)
	at java.io.FileInputStream.<init>(Unknown Source)
	at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
	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)

Console:
Java Web Start 1.6.0_01
Using JRE version 1.6.0_01 Java HotSpot(TM) Client VM
User home directory = D:\Documents and Settings\aa015037
----------------------------------------------------
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
0-5: set trace level to <n>
----------------------------------------------------
#### Java Web Start Error:
#### Could not load file/URL specified: D:\Documents and Settings\aa015037\Application Data\Sun\Java\Deployment\cache\6.0\59\1c52e23b-1084115d


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
These changes seem to help with this demo draw app example:
- remove the <property> -tag
- remove os="Win" attribute from resource tag
- change os="Win" to os="Windows"
Posted Date : 2007-05-31 12:57:43.0

N/A

from the latest comments from developers on http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6563938, this might be fixed by 6809125: Desktop short-cut doesn't work for java application after installation of 6u12

fix will be in 6u14
Posted Date : 2009-02-25 19:50:43.0

This is a huge deployment blocker for our application. We see this regularly when many jar files change in our project, and have to ask users to clear their temporary java files to fix this. 

Please apply appropriate priority here. 

Oh, that's sweet! Now for an unknown reason the application simply does not start! And guess what? You have to tell users to clear the JNLP Cache and MAYBE it will work! Isnīt that amazing? JWS is the only technology that I have ever seen that gets worse as the time passes!  

We have been bumping into this issue more and more.  I would agree with GarryTan.  Everytime we update our JAR files, the first time we try to load the updated app from our server, we bump into this problem.  Asking our field engineers and users to clear the Java cache is ridiculous.

A primary purpose of JWS should be to make Java applications palatable to end users. If it worked as advertised, this would be a major reason to develop and deploy Java-based applications. However, the user experience of JWS is abysmal. 

I am in alpha of my project (http://playawaken.com/), using JWS. I will not even deploy beta with JWS unless this is fixed.

Submitted in May, and still an "open bug"  This causes our support department havoc on a daily basis.  We are almost to the point of scrapping Web Start and trying a different approach.  Very damaging to Java, and may cost me my job.

Related Bugs.
6570739 - Marked as Closed, not reproducible
6549428 - Same error but reported against the Single Instance Server (Also Closed, then finally re-opened) 

The automatic upgrade functionality is one of the main reasons to choose Java WebStart in the first place. When this core functionality is broken, one starts regretting having chosen JWS as main deployment technology...
We loose credibility on our customers when we have to demand of them to remove and reinstall the application to get around this bug...

This is a *major* impediment to using Web Start for releases.
We provide applications to the financial/equity trading community – and our customers will not accept this much longer.

Web Start updates were broken on Java 6 (original), update 1, update 2, and update 3.
It still appears to be broken in the early access update 4.

Why is this taking 4+ releases to fix?

Can you please provide a testcase or exact steps to reproduce the problem ?

When the problem occur, do you launch from the web browser ?  or from the application desktop shortcut ?

I cannot reproduce the problem by just following the steps in the bug report.

Also, can you try the latest 6u10 build and see if the problem still exists ?

Right now it's at 6u10 b11
http://download.java.net/jdk6/binaries/

My error instance with a user:
- Occurred by clicking on the desktop icon monday, while the application was upgraded last friday. User is using java 1.6.0_01 and javaws 1.6.0_01

Collegue's tell me this bug happens with all users, on all java versions: you just got a random chance java webstart breaks after an upgrade.

This is a unacceptable bug from a layman user point of view.

How can Sun make a layman user,developers and system administrator concern about the JWS caching on client desktop software for software update when competitor A and competitor M doing all these sliently and gracefully.

This does not seem to occur anymore with 1.6.0_05, at least with the exact steps mentioned in the report.

I'm seeing this problem as well with a user running jre1.6.0_05.  However, I also notice that the deployment.javaws.version property also indicates that the launch was done with javaws 1.4.2_05.  Something to look at here is the version of WebStart being used on a client may not match the version of the JVM.

My previous comment about the version of javaws is probably a red herring.  I've confirmed that JavaWS 1.6.0_06 is running on my system, yet the 'deployment.javaws.version' property reported by the application is still '1.4.2_17'.  There is probably some separate issue with this version property.

One of our users experienced this same error this morning.  Its seems pretty clear from the exception traces that the client was run from a desktop shortcut referring to a copy of the JNLP file stored in the deployment cache.  That copy of the JNLP file no longer exists in the cache.

This looks like a pretty shaky design if you ask me.  Is a permanent shortcut on the desktop really referring to a temporary cache file?  Is WebStart somehow guaranteeing that these cached JNLP files don't get deleted when the cache starts to reach its limit?

If not, this is a design flaw.  If it is, then maybe you should look into whether that code really is guaranteeing the file won't be deleted.

I have just experienced this problem also, the client (user) is running JDK 1.6.0_02 on Windows.  The error he gets is:
CouldNotLoadArgumentException[ Could not load file/URL specified: C:\Documents and Settings\ed.randall\Local Settings\Temporary Internet Files\Content.IE5\4AOV1PR8\bedrock-jnlp[1].jnlp]
	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)

It seems that Web Start launch is looking for the .jnlp file locally on disk, and it expects it to be physically located in the browser cache.

My .jnlp file is being generated on-the-fly using a .jsp page, but the list of .jars comprising the client changes frequently during development so we don't want the browser to cache the .jnlp file as an incorrect launch sometimes results.  So  I disabled browser caching of that page by setting the following headers:

    response.setHeader( "Pragma", "no-cache" );
    response.setHeader( "Cache-Control", "no-cache" );
    response.setDateHeader( "Expires", 0 );

Now some testers have encountered the error that is the subject of this bug.  I deleted the Cache-control: no-cache header setting, and the problem is now resolved.  So this could be a possible workaround for Internet Explorer users.

This is a critical bug. Why is it at medium priority? If this issue occurs on the field, it means we need to get support personnel on the field to reinstall the application at customer site stalling transactions that run in millions of dollars.

This problem has been affecting our clients for several months, since we started using Java 1.6.  The problem continues with Java 1.6.0_11.  In fact, even when jar files have not changed the error can (apparently randomly) occur.  Although this does not affect all users each time, it is frustrating to ask users to re-install our application to permit it to run.  Our client aren't happy about it either...

This is occurring for us also and is reproducible. We cannot remove the properties tag. We do not use OS tags. I request that this be fixed ASAP.

This is occurring with 1.6.0_12-b04 and is causing customer support problems.

Also seeing this on 1.6.0_12-b04. Come on Sun - you need to raise the priority on this one!

Forgot to mention:
- Not using property tag
- *Are* using os tag, with "Windows"
... so reporter's workaround doesn't apply.

One more note, I can launch the application from running "javaws -viewer" at the DOS command prompt, and can launch it both online and offline.  It's the desktop icon that fails in 1.6.0_12-b04.  

I had the similar error by executing the Desktop-Link of my Webstart-App after an update of resources has been available. In that case the Installer dumped the CouldNotLoadArgumentException.
But after I closed the Webstart Dialog with the error and executed the Desktop-Link again, the Installer updated and started successful.

The solution (at least for my JNLP configuration):
I experienced using the <j2se> element within the JNLP file without any other attributes but version leaded to a successful update through Desktop-Link at first trial, i.e. I got no error message any more.
Before my j2se tag was like this:

    <j2se version="1.6" initial-heap-size="256m" java-vm-args="-Xmx256m" />

now I have this:

    <j2se version="1.6" />

We've been experiencing this same issue, patiently waiting for it to be "fixed".  I have been able to reproduce it by just updating the date/timestamp on the jnlp file (touch client.jnlp).  The Evaluation above indicates it will be fixed in 6u14.  Let's hope so.

please try and see if you can reproduce with 6u14.  you can download 6u14 snapshot here:

http://download.java.net/jdk6/index.html

if you can still reproduce with 6u14, please post the exact steps to reproduce the bug.

I can reproduce this Bug with 6u14 on WinXP.-

This is how to reproduce the bug on my system:
1. make sure your browser's cache limit is nearly reached
2. touch jar-file on server to indicate it has changed.
3. start application via browsers webstart with jnlp-file.

I can reproduce this bug using java version 1.7.0-ea (build 1.7.0-ea-b66)! All that it takes is for the end user to rename the desktop shortcut. The next time I send the server an update the user gets this error and needs to remove my application from cache and download again to get it to work.

Update to the above: For my evaluations, this "rename shortcut" bug seems to affect at least versions 6u3, 6u14 and 6u15. With 5u14 this didn't seem to happen.

Hi,

for me and my application, bug 6809125 seems to be fixed in 6u14 and 6u15 (which I have tried). BUT: There is still one somewhat related bug that seems to be reproducable (at least with my application & Windows Vista/2K environments that I have tried):

1. Get the JNLP application from network (desktop shortcut is created)
2. Rename the desktop shortcut
3. Touch the JNLP file at the server
4. Run the application from the desktop shortcut : works fine
5. Run the application again from the desktop shortcut : CouldNotLoadArgumentException with similar stack trace as at the bug description.

Hope to get this fixed soon...