Desktop.getInstance().open(file) does nothing (nothing happens)

Question

I 've seen this on a user's computer:
Desktop.getInstance().open(myFile);
does nothing: no exception, no stacktrace, nothing.
It doesn't work for pdf or for xls files (and probably for all other file types too).
However, if he double clicks on a pdf or xls file in Windows Explorer it opens (in acrobat reader / MS Excel).
This also works in DOS-prompt: "start C:\myFile.pdf"
Making it canonical first doesn't work either:
Desktop.getInstance().open(myFile.getCanonicalFile());
Environment:
Java 6 update 16
Windows XP SP 3
A webstart application with all security permissions.
I've removed all JRE's and even removed the USER_HOME/application data/Sun map.
He upgraded from Windows XP SP2 to SP3 with no change.
Has anyone any idea what is causing this?
This problem has been metioned before, but they don't mention a cause or solution: http://forums.sun.com/thread.jspa?threadID=5338022

Answer 1

Hi,
I also have the same problem, but with my JNI and C++ expertise, I was able to isolate the problem.
My platform:
- Microsoft Windows XP, Family Edition (French), Version 2002, Service Pack 3
- JRE 1.6.0_21
In the source of the JDK6 (Src/windows/classes/sun/awt/windows/WDesktopPeer.java), the Desktop.open(file) calls the native method
ShellExecute(*uri.toString()*, "open")
For example, if you try to open "c:\helloworld.pdf",
uri.toString() = "*file:/c:/helloworld.pdf*"if I call ShellExecute("C:\\helloworld.pdf", "open"), it works
but if I call ShellExecute(" file:/c:/helloworld.pdf", "open"), it doesn't work on my platform.
In both case, the ShellExecuteW or ShellExecuteA function of the Windows API return the integer 42 (> 32), saying that the functions succeeded. If the file object is not correct, the function should return a value <= 32.
=> The bug is not due to Java implementation, but to a bug in the Windows API.
Other remark:
I also tried the "ShellExec_RunDLL" entry point of the Shell32.dll library using RunDll32 utility. Both commands below are running correctly:
rundll32 SHELL32.DLL,ShellExec_RunDLL "C:\hello.pdf"
rundll32 SHELL32.DLL,ShellExec_RunDLL "file:/C:/hello.pdf"My conclusion:
1) A workaround could be implemented in the JRE: use the file path without the "file:/" protocol prefix.
2) This bug seems to be present only one some version of Windows XP (to confirm).
Rodolphe.