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 :
Shortcut stops working if jnkp file of a signed jar changed on server.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Sign a Java application.
2. Install a Java Webstart deployed software via its online jnlp, making sure the jnlp file contains:
 <offline-allowed />
     <shortcut>
      <desktop/>
    </shortcut>

3. Allow the install of the shortcut.
4. Change something in the jnlp file. ie. Change SEVERE to WARNING in demo JNLP.
5. Try to run the application with the shortcut.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Exp. result: the application starts.
ACTUAL -
Act. result: an error message appears: Unable to launch the application

ERROR MESSAGES/STACK TRACES THAT OCCUR :
CouldNotLoadArgumentException[ Could not load file/URL specified: C:\Documents and Settings\John\Application Data\Sun\Java\Deployment\cache\6.0\34\38fa84a2-422f80a7]
	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.

---------- BEGIN SOURCE ----------
<?xml version="1.0" encoding="ISO-8859-2"?>
<jnlp spec="1.0+" codebase="http://example.com" href="myapp.jnlp">

  <information>
     <title>Title</title>
     <vendor>Vendor</vendor>
     <homepage href="index.html" />
     <description>Description</description>
     <offline-allowed />
     <shortcut>
      <desktop/>
      <menu submenu="My Application"/>
    </shortcut>
   </information>

  <resources>
     <j2se max-heap-size="128M" version="1.5+" 
href="http://java.sun.com/products/autodl/j2se"/>
     <jar href="myapp.jar" main="true" />

<property name="myapp.log.level" value="SEVERE"/>
</resources>

  <application-desc main-class="MyApp"/>

  <security>
     <all-permissions/>
  </security>

</jnlp>
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Uninstall the application and install again.
Posted Date : 2007-04-24 02:31:38.0

Same issue reported by a CAP member:

Encountered a problem with their deployments with Sprint and Electronic Arts that happens with the latest Java 6 JRE.  Both accounts are using the desktop icon shortcut to launch their respective applications, and both are encountering this bug -- which renders their desktop icons non-functional with cryptic user-visible error messages.
Posted Date : 2007-05-17 21:22:34.0

the CAP member can still reliably reproduce it on the early access release, and so can some of 
the other users 
based on the comments.  Attached is their a reproducible test case:

http://content.mpowerplayer.com/hosting/java.com/
Posted Date : 2007-06-07 15:06:10.0

N/A

cannot reproduce with 6u2 b02 or b03.  b02 can be downloaded from:
http://download.java.net/jdk6/binaries/
Posted Date : 2007-06-01 23:50:36.0

i can reproduce the problem with customer's test case.

customer's jnlp application is using single instance service, and registered as a single instance application.

if you just close the application window, the instance won't go away, and now if you click on a different jnlp file, the single instance code will bring up the application using the running jvm again, but also it will  update the cached jnlp, but not the desktop shortcut.

problem only exists for single instance application.  normal jnlp application does not have the problem.

need to investigate 2 things:

1.  why the incoming new instance will go into the java code ?  the native code should be able to detect the single instance too, so it should not get into the java code at all.

2.  for the case it needs to get to the java code, if we are still running the same instance, we should not update the cached jnlp file ?
Posted Date : 2007-06-11 20:01:45.0

Problem:  

Shortcut stops working if jnlp file changed on server while running single instance application

two issues shown by the customer's application:

1.  if another instance of a single instance application is started and we need to go to the java code, we should not update the cached jnlp.  instead, as soon as we got a LaunchDesc, we should check if another instance of the application is running, and signal and exit if necessary.

2.  launching of the second instance via jnlp file directly should not launch java at all.  the native code should be able to signal the current running instance already.   problem here is the customer's jnlp file uses multiple resources element, and main=true is not specified.  our native code fail to read the correct resources element to find out the first jar as main jar.

Fix:

1.  check for single instance as soon as we have a LaunchDesc
2.  native code should process the valid resources element to find out the main jar

testcase: http://web-east.east.sun.com/deployment/www/tests/1.6.0_10/6549428/
Posted Date : 2008-04-23 00:03:49.0

I faced similar problem.

The JNLP is cached if you launch from the shortcut, while the web link works.  This is a very serious BUG, why the sun engineers couldn't reproduce is beyond me.

Also happens with b06

I tried with update 2 and the shortcut works.

We can reproduce on b06.  Please re-open and kindly raise the priority.  We need you to fix and ship this one as soon as humanly possible.

We can reproduce on b06.  Please re-open and kindly raise the priority.  We need you to fix and ship this one as soon as humanly possible.

Please see the evaluation: cannot reproduce with JDK 6 update 2.
I think you are talking about JDK 6 update 1 b06, which is the version I reported the bug for. 

Please fix and deploy as soon as possible, it unexplainable to end-users why off-line webstart applications crash.

Very damaging to java as a application platform!!

I have dowloaded the 1.6.0_02-ea release, and tested its WebStart component against this bug.

Shortcut keeps working each time the JNLP file is modified.

Maybe the previous status of this bug "Closed, not reproducible" leads to some misunderstanding.

Instead it should have been: "Closed, fixed in 1.6.0_02".

Correction: we tested against 1.6.0_02-ea-b02

Updated the test case to be more clear:
http://content.mpowerplayer.com/hosting/java.com/

Having the app running when launching a second jnlp file seems to make a difference.

(Also, is there any way my profile can be changed so that it doesn't expose my email address to spammers?  There appears to be no option to do so on my profile.)

Something along the same lines. If you copy your shortcut to the quick launch bar (or rename the short cut) and then change your jnlp file, the copied shortcut will work the first time, but will not work subsequently, receiving the error in this bug report. Our helpdesk got flooded with calls when I changed the jnlp the other day. I think changing the target of a shortcut is unacceptable.

We've found two other reproduceable situations in which the shortcut stops working (points to a cached version that no longer exists): 

1) Click the 'cancel' button at just the right time while the app is updating.

2) Simulate a network error (i.e. yank the network cable out of the back of your machine) while an app is updating,

Also, ditto about bob90's comments about it being unacceptable to change the target of a shortcut.  For better or worse, the assumption that any windows user will have regarding desktop shortcuts is that they can be moved/copied & still work (or at a minimum, be copied to the quick-launch bar).

Here's a "Related Bug".  The client runs a stale JNLP from the desktop shortcut but works from web page:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6570739

With 1.6.0_02 this is still an issue!

JWS attempts to use the stale JNLP and simply will not use the updated JNLP when launched from the desktop link or the web url.

In our use case, adding a resource to the JNLP causes the app to fail since the stale JNLP is used by JWS. JWS does not download the new resource. The class which utilizes classes in the new resource fails to load with a class not found exception.

The only work-around (although unacceptable) is to uninstall the application or delete the jnlp from the JWS cache.

Corrected to comment posted on 30-JUL-2007:

The issue noted in the comment where the cached stale JNLP was never updated may be unrelated to the bug reported above.

For those of you watching this bug, we were able to resolve our issue by adding a Last-Modified header to the jnlp file response which is constructed via JSP. It appears that with 1.6.0 the Last-Modified header is key to getting Web Start to update the cache for the jnlp.

This bug is still reproducible with 1.6.0_3 and both Windows XP and Vista.

Simply renaming the desktop shortcut breaks the shortcut after an update. After renaming the shortcut, the first launch/update works fine. The second and all subsequent launch attempts fail with a “CouldNotLoadArgumentException” as detailed in the bug report above.

To recover, one must delete the desktop shortcut, remove the application, and clear the JWS cache. The severity of this bug makes JWS un-usable as an application deployment mechanism.

Please increase the priority for resolving this issue.

This bug has become a major problem for us, since we have lots of clients running an offline jnlp application. Every time we update the application, we have to manually recreate the desktop shortcut.

Please fix this as soon as possible

This bug is STILL REPRODUCABLE with Java Web Start 1.6.0_05!

PLEASE, PLEASE fix this bug as soon as possible.

+1 to raise priority to blocker

PLEASE, increase the priority. Its a blocker bug. I'm having too many problems with my clients because. Its making JWS very difficult to mantain.

PLEASE, INCREASE PRIORITY!!!

Do users have to install 6u10(b24) or greater manually or can you enforce through the webstart jnlp j2se version that the user has 6u10(b24)?

Also, does this fix address bug ids 6563938 & 6446676?