Bug ID: JDK-6488081 JFileChooser on Vista: Cannot enter user or "Public" directory

Versions (Unresolved/Resolved/Fixed)

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.

Other	JDK 6
5.0u12Resolved	6u1Resolved

JFileChooser won't go into the user or "Public" directory if attempted from the "Desktop" folder (Win L&F) on Vista:

- open file chooser
- click "Desktop" button on the left
- try to enter either your own or "Public" directory - 
  it won't go in. No exceptions are being thrown on the
  console.
- you can enter the user dir if you use some other
  route (like c: -> c:/users/ -> c:/users/<user dir>)
     
I've verified that older Win32 app (WinZip) could enter
the same directory from the "Desktop" folder.

SUGGESTED FIX a) in ShellFolder2.cpp, add COM initialization in the native implementation of Win32ShellFolder2.getEnumObjects b) in Win32ShellFolder2.getFileSystemPath, if the current implementation returns a non-existing path on Vista, obtain it via native call to SHGetPathFromIDList.
07-11-2006
EVALUATION Further investigation shows that special folders like Public and user are located in the wrong places in the shell folder heirarchy. This is caused by the fact that Win32ShellFolder2.getFileSystemPath returns a non-existent path for them what didn't allow these folders to be entered in JFileChooser. In such cases, system path should be obtained via SHGetPathFromIDList. After this issue was fixed, the user folder became accessible but its content was not shown. It was caused by the native implementation of Win32ShellFolder2.getEnumObjects that required COM to be initialized prior to the call, otherwise it returned null pointer to child shell folders enumeration.
07-11-2006
EVALUATION The file system APIs don't know anything about Windows virtual folders. To make use of these folders they need to be translate (via the registry) into paths to directories in the file system.
02-11-2006
EVALUATION The cause of this bug is that java.io.File.exists() returns false for virtual Windows folders like "My Documents". We tried to use java.io.File.getAbsolutePath() and failed because it binds virtual folders with the application working dir instead of its real absolute location. For example, it resolves My Documents as C:\tmp\test\My Documents if SwingSet2 is started from C:\tmp\test.
02-11-2006
EVALUATION Need to investigate why ShellFolder.isFileSystem() returns true for "Public" dir.
01-11-2006

Duplicate :	JDK-6491795 - COM should be initialized for Shell API calls in ShellFolder2.cpp
Relates :	JDK-6488082 - JFileChooser on Vista: User dirs not shown properly