JDK-4905313 : JFileChooser setCurrentDirectory() ignores FileSystemView model
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-08-12
  • Updated: 2005-09-12
  • Resolved: 2005-09-12
Related Reports
Relates :  
Description
Name: jk109818			Date: 08/12/2003


FULL PRODUCT VERSION :
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)

FULL OS VERSION :
Not OS specific

A DESCRIPTION OF THE PROBLEM :
I'm trying to display a JFileChooser on a client system (that happens to be Windows) that will allow the user to browse the filesystem and open files from a remote system (that happens to be UNIX).  To do this, I've created RMI versions of the FileSystemView and FileView classes, and created a JFileChooser using these.

This allows me to see all of the files and directories in the home/default directory when the dialog is first displayed.  However, I cannot navigate in the dialog box - any attempt to move downward (by selecting a folder icon) or upward (by clicking the parent directory icon) leaves me with the same directory view.

I've tracked this down to the following code in JFileChooser.setCurrentDirectory:

    public void setCurrentDirectory(File dir) {
	File oldValue = currentDirectory;
	
	if (dir != null && !dir.exists()) {
	    dir = currentDirectory;
	}
	if (dir == null) {
	    dir = getFileSystemView().getDefaultDirectory();
	}
	if (currentDirectory != null) {
	    /* Verify the toString of object */
	    if (this.currentDirectory.equals(dir)) {
		return;
	    }
	}

The dir.exists() call is ignoring the model-view separation that is supposedly provided by the FileSystemView and FileView classes, and directly accessing the local file system.  I think this is an unnecessary check - if a FileSystemView has been set, and both the FileSystemView and FileView report that the given file isTraversable(), then set the directory and trust the model.



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create FileSystemView and FileView objects that represent a file system other than the local file system where the application is to be run.  This might represent a remote file system, or a virtual file system, or anything else you can imagine.

Create a JFileChooser passing the FileSystemView to the constructor (calling setFileSystemView() after construction will not work).  Then set the FileView with the chooser.setFileView() method.

Display the JFileChooser.  Try to navigate by selecting a directory in the view, or by clicking the parent directory icon.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expect navigation to work just as it does with a real local file system.
ACTUAL -
If I select a directory, the dialog exits with APPROVE_OPTION and the directory name can be returned by getSelectedFile().  No navigation happens.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages or exceptions.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
I tried a workaround based on the fact, as observed in the JFileChooser source code, that a 'null' directory passed to setCurrentDirectory() results in the directory being set to FileSystemView.getDefaultDirectory(). So I added a setDefaultDirectory() method to my FileSystemView, and if JFileChooser.getSelectedFile() returns a traversable file, then I call FileSystemView.setDefaultDirectory() followed by JFileChooser.setCurrentDirectory(null).  This allows me to navigate downward, but not upward, in the hierarchy.
(Incident Review ID: 185878) 
======================================================================
###@###.### 10/13/04 18:38 GMT

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
26-09-2004

EVALUATION Unfortunately, there are many places in JFileChooser where we depend on calling methods on the File objects. Therefore, a custom implementation of FileSystemView must generate File objects that implement these methods correctly. In this case, the exists() method should call the remote File object's method over RMI.
26-09-2004