United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6809125 Desktop short-cut doesn't work for java application after installation of 6u12
JDK-6809125 : Desktop short-cut doesn't work for java application after installation of 6u12

Details
Type:
Bug
Submit Date:
2009-02-24
Status:
Closed
Updated Date:
2011-03-07
Project Name:
JDK
Resolved Date:
2009-05-17
Component:
deploy
OS:
windows_xp
Sub-Component:
webstart
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10,6u12
Fixed Versions:
6u14 (b03)

Related Reports
Duplicate:
Duplicate:
Duplicate:

Sub Tasks

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/
                                     
2009-02-25
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.
                                     
2009-02-25



Hardware and Software, Engineered to Work Together