Problem / Bug:
For the last one and a half day I have been investigating a very curious problem. On one Windows XP machine here on our company network (my machine) the following line of code fails without any exceptions thrown:
java.awt.Desktop.getInstance().open(new File("C:\\test.txt"));
The test.txt file is there. It opens normally when I double click it. Furthermore I can open it from Java using the (platform specific) Runtime API code:
Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler C:\\test.txt");
Also, if I invite some other user to log on to my machine and run the test application, it does work for him. I have created a new (local) account and for that account it did work. If i log onto some other machine with my network account and run the test application there, it works normally. Only on this specific machine with this specific account does the problem occur.
The machine is a Windows XP machine with SP3 applied and all patches installed, also the optional ones.
An interesting thing is that if I put the local test account, for which the test app is working, in the local Administrators group, suddenly this account has the problem as well. If I remove it from the Administrators group, the problem disappears again. Very strange. It must have something to do with profiles/policies/permissions… but what? I have no idea.
I am giving up on this for now because it’s eating so much time, but I will post a link to this message around in some relevant places and invite anyone seeing similar behaviour to post their findings here. Together we may be able to crack this nut.
Symptoms:
- Desktop.open() fails without throwing any exception
- Desktop.isDesktopSupported() returns true
- Runtime.exec() does work
- Occurs for some user account, but not for others
- Windows file associations etc. all normal, app launches when double-clicking file in Windows.
Related references:
Desktop.open fails without exception, nothing happens
Desktop.getInstance().open(file) does nothing (nothing happens)
Desktop.open() method doesn’t work
Stijn de Witt 
I’ve just encountered this exact problem but I haven’t tested it under different user accounts. Have you found any solution to this? I ended up using your Runtime suggestion and it works but I’d like to use java.awt.Desktop if possible.
Cheers
No sorry, the only solution I found so far is reverting to Runtime. I agree it is not a nice solution but at least the problems in that one are documented and can mostly be detected and worked around.
For this problem in the Desktop API I haven’t found any way to detect it or work around it… which basically means that when we use the Desktop API we have an x percent chance of it failing silently without any clue why or even that it happened.
As a last resort you could provide an option to your users: Use the Desktop API by default and let the user toggle to ‘Legacy mode’ or something when they encounter problems.
If you ever find a migitating factor I would be very interested to know about it. The Oracle blog guys keep closing all related topics and actively removed my links to this blog from it so there is no way to build up a history there… which is really what is needed here because we need to find the common factor that causes it. It seems to be something to do with permissions or profile settings but as to this date I did not found out what it is.
stijndewitt, i’m having the exact same problem. Where you able to find any solution to this?
Thanks in advance.
Federico.
I have the same problem too (Windows XP, Admin account).
But when I change Desktop.open to Desktop.browse, it works (even for a text file, using the default application for this kind of file…)
That sounds interesting Arnaud. I never thought of trying that… Does that have the same effect? Are there sideffects? I will have to look into that one…
Exactly the same problem (runs on a Vista box, but not on a XP one from an admin account). The ‘browse’ action works.
So, browse() sounds like an interesting alternative to open(). Unfortunately, the same issue that is present in open() also seems to be there for print() and I don’t know of an alternative for that except writing some really tricky code to print from the command line using Runtime.exec()…
But the good news is that it seems that this issue only exists on Windows XP. I have not encountered any reports of this occurring on Windows Vista or later. And since Windows XP is now over 11 years old, we can probably all forget about this issue soon.
Same issue on Windows 7 with java 6 update 38 :(!!!
Even if the user is not an Administrator
Darn it Antimo, that is bad news! Thanks for reporting it though!
If you figure out what causes it, please let us know.
Oracle moved some stuff again, so the Related references that I added at the bottom of this article were dead. I found them again and updated them.
I’ve experienced the same thing. I can only contribute another string for the hacker style solution
Runtime.getRuntime().exec(“rundll32 SHELL32.DLL, ShellExec_RunDLL “+s);
I had the same problem and tracked it to the used java version:
– No problems: jre7 (1.7.0_71 ?)
– Exactly the issue above: jdk1.7.0_25
I cannot say where exactly the problem sits but I had two exactly identical uses with the different libraries and switching them worked.
Line used was
Desktop.getDesktop().open( Paths.get(“test.txt”).toFile() );
Specs:
– Using Eclipse version: Juno Service Release 1 (Build id: 20120920-0800)
– jre7 (1.7.0_71 ?)
– jdk1.7.0_25