JDK-6385002 : all Desktop methods (browse, open etc.) only accept canonical path
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-02-13
  • Updated: 2011-04-29
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-rc-b70)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b70, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
All methods of java.awt.Desktop only work if
path are canonical (at least on windows).



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
run the test case

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
open an explorer on the current directory.
ACTUAL -
an IOException (see below)

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.io.IOException: Failed to open file:/C:/java/workspace/java-patch/./. Error message: Le chemin d'acc����s sp����cifi���� est introuvable.

	at sun.awt.windows.WDesktopPeer.ShellExecute(WDesktopPeer.java:59)
	at sun.awt.windows.WDesktopPeer.browse(WDesktopPeer.java:52)
	at java.awt.Desktop.browse(Desktop.java:348)
	at DesktopBug.main(DesktopBug.java:11)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.Desktop;
import java.io.File;
import java.io.IOException;
import java.net.URI;

public class DesktopBug {
   public static void main(String[] args) throws IOException {
    Desktop desktop=Desktop.getDesktop();
    URI uri=new File(".").toURI();
    //URI uri=new File(".").getCanonicalFile().toURI();  // works
    desktop.browse(uri);
  }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
use getCanonical() before transform the Fil to an URI.

Comments
EVALUATION I investigated the problem further. I used only Win32 API function ShellExecuteW for my investigation and discovered that: 1. ShellExecuteW indeed cannot handle "." if it was passed as URI for file (file:///C:/temp/.). 2. ShellExecuteW does not understand URI if we ask to OPEN mpg file. It always returns "the system cannot find the file specified" error. 3. ShellExecuteW opens fine text file's URIs (like "file:///c:/temp/1.txt" and even "file:/c:/temp/1.txt") 4. If we ask ShellExecuteW to make default operation on .mpg URI it open WMP. 5. ShellExecuteW opens .mpg file if I pass into the function canonical path to the file. Looks like in the case with .mpg the real problem is in Windows's register. WMP was registered so that .mpg coud not be opened using URI passed to ShellExecuteW. Here we could pass to ShellExecuteW() pathes instead of URIs. The same solution is for "." directory. But we cannot use pathes in case of browsing. Here we have to handle URI for files as fine as for URL's.
2006-03-27

EVALUATION -- This may not be an issue with File's toURI method. Consider the following experiments with the ShellExecute API: file:/C:/temp => okay file:/C:/temp/. => error file:/C:/temp/./ => error file:///C:/temp => okay file:///C:/temp/. => error file:///C:/temp/./ => error so even if toURI() returned file:///C:/temp/./ it appears that ShellExecute will still reject it. I suspect this can only be fixed in sun.awt.windows.WDesktopPeer.
2006-03-25

EVALUATION The problem is in File.toURI() method. See: 6351751 File.toURI generates non conforming file: url
2006-03-24

EVALUATION feature wasn't implemented
2006-02-15