Name: gm110360			Date: 05/30/2002


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


FULL OPERATING SYSTEM VERSION :
windows 2K

ADDITIONAL OPERATING SYSTEMS :
windows xp


A DESCRIPTION OF THE PROBLEM :
JFileChooser can no longer be used to browse virtual file
systems (for example, a virtual folder hierarchy stored in
a database) because code in the UI objects assumes that
all directories are descendents of system root folders, as
implemented in class sun.awt.shell.ShellFolder.

The effect is that navigating the virtual filesystem fails
to update the directory-combo-box at all, since the
virtual directories do not descend from anything that
ShellFolder knows about.

Since the swing.filechooser package provides the ability
to define [virtual] filesystem roots, it is wrong for
other parts of Swing to presume to know what they are and
to behave incorrectly if they're different.

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Define a subclass of JFileChooser that has its own
implementations of FileSystemView and FileView that are
based on something other than the normal filesystem.  This
is no picnic, by the way, and in my case also requires a
special subclass of java.io.File with non-standard
behavior.
2. Try navigating with the JFileChooser.
3.

EXPECTED VERSUS ACTUAL BEHAVIOR :
In 1.3.1, everything works great.  The virtual filesystem
is displayed and manipulated correctly by the
JFileChooser.  In 1.4, the directory-combobox does not
function properly at all.
The reason for the failure is that the FileChooserUI
classes are using ShellFolder unconditionally to set up
the combobox, rather than using the set of root folders
provided by the FileSystemView.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Sorry, this one's too non-generic to supply sample source.
---------- END SOURCE ----------

Release Regression From : 1.3.1
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 146098) 
======================================================================


In order to browse a remote system's file system, I am overwriting
FileSystemView (my new class name: RemoteFileSystemView) and sending it as
an argument to JFileChooser. I am using FTP Protocol underneath to get the
remote system's directory and file names.

In my RemoteFileSystemView I overwrite the following methods of
FileSystemView:
File createFileObject( File dir, String filename )
File[] getFiles( File dir, boolean useFileHiding )
File getHomeDirectory()
File[] getRoots()
isRoot( File f )

With 1.3.1 JRE my code works perfectly. But with 1.4.1, it is not.

Here is the flow for 1.3.1:
First it (JFileChooser) calls getRoots on RemoteFileSystemView. My
function returns fs0: (I am browsing a 64 bit machine).
Then it calls getFiles on fs0: drive. I return two file objects which
happens to a directories.
Then if I choose one of the directory from JFileChooser display, it
promptly calls getFiles on that directory and displayes any files under that
directory.

Everything works perfectly and I am happy :) until I run the same code on
1.4.1 JRE.

Here's the flow for 1.4.1:
First it (JFileChooser) calls getHomeDirectory. My code returns fs0:.
Which is right.
It never calls getFiles on fs0:. Which is a problem.
Then JFileChooser checks to see if c:\Docukents and Settings\saddanki\My
Documents isRoot.
Then it displays My Documents and fs0: in JFileChooser's drop down list
box for drives.
Now when I select fs0: as the drive it never calls getFiles() on fs0:
hence I never get to see the remote files and make a selection. Hence my
remote browsing is failing. Any ideas?? Has anyone encountered any such
problem??


Srinivas Addanki
Sr. Software Engineer
EPSD
Intel Corp. Hillsboro, OR

###@###.### 2003-02-24

=======================================================