JDK-6809125 : Desktop short-cut doesn't work for java application after installation of 6u12
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u10,6u12
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2009-02-24
  • Updated: 2011-03-07
  • Resolved: 2009-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u14 b03Fixed
Related Reports
Duplicate :  
JDK-6812258 - Java Web Start downloads use illegal If-Modified-Since headers
Duplicate :  
JDK-2190375 - JNLP Shortcut not working
Duplicate :  
JDK-6826530 - JNLP Shortcut not working
Description
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.
Comments
SUGGESTED FIX http://web-east.east.sun.com/deployment/www/webrevs/ngthomas/6809125/webrev/
25-02-2009
EVALUATION 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.
25-02-2009