Java Tip 85: Fun and games with JFileChooser

The JFileChooser dialog class is one of the most useful classes that Swing provides. It allows users to choose either a single file or multiple files that match specified file filters. It provides Java programs with a platform-independent GUI component that does the same job as Internet Explorer under Microsoft Windows and Unix’s File Manager.

Imagine the following scenario: your user wishes to open a specific file on a specific drive so that she can edit it using your text-editing program. How do you help her do this? Windows and Unix applications provide a file dialog box, allowing the user to select the file she wishes to see. Wouldn’t it be nice if the same capability existed in Java? Fortunately, there is JFileChooser, a platform-independent version of this file dialog box that provides this capability.

In this article, I’ll show you how to use JFileChooser effectively, as well as help you avoid some of its pitfalls. I’ll show you how to set filters so that your users only see certain file types, how to set and handle the directories, and how to determine which files the user has selected.

A simple JFileChooser

Swing provides a free, platform-independent

JFileChooser

class. To use it, all you need to do is instantiate it (as you would with any other object) and show it to the user.

  //for a default JFileChooser using the default directory
  JFileChooser fc = new JFileChooser();
  fc.showOpenDialog(<i>parentComponent</i>)
  //where the '<i>parentComponent</i>' is normally
  //a JFrame or a JDialog.

Since I have not specified the directory that the JFileChooser should use, it will use a default. Since there is no concept of a current directory in Java, JFileChooser defaults to using the user.dir, which is defined in the system properties. The JFileChooser has six constructors. Three of these are of particular interest to us:

• JFileChooser(): Creates a JFileChooser pointing to the user’s home directory
• JFileChooser(File currentDirectory): Creates a JFileChooser using the given File as the path
• JFileChooser(String currentDirectoryPath): Creates a JFileChooser using the given path

By using the last two constructors listed above, you can set the initial directory. The following examples demonstrate how to do this in a Windows environment:

    //with the string representation of the path
    JFileChooser fc = new JFileChooser("C:temp");
    fc.showOpenDialog(<i>parentComponent</i>)

   //using a file object as the directory rather than a String
   File file = new File("C:temp");
   JFileChooser fc = new JFileChooser(file);
   fc.showOpenDialog(<i>parentComponent</i>)

Each of the examples above creates a

JFileChooser

that displays the contents of the default or specified directory to the user. The filters (marked as such on the figure above) will default to All Files and *.*.

Handling the user’s response

Displaying the

JFileChooser

is all well and good, but as of yet we have no way to obtain the user’s response. As it stands, any choice the user makes will cause the

JFileChooser

dialog to disappear, without the program ever doing anything about the user’s actions. Programs can determine which file the user selected in the following manner:

  JFileChooser fc = new JFileChooser();
  
  //the "this" in the below code is the JFrame that acts as the 
  //parent to the JFileChooser dialog.
  int returnVal = fc.showOpenDialog(this);
  //declare the file object
  File selectedFile = null;
  //OR handle multiple files with
  //  File[] selectedFiles;
  //this accounts for multiple selected files.
  
  //Query the JFileChooser to get the input from the user
  if(returnVal == JFileChooser.APPROVE_OPTION)
  {
    selectedFile = fc.getSelectedFile();
    // OR 
    // selectedFiles = fc.getSelectedFiles();
    //to handle multiple returns.
  }

The code fragment above allows the user to select a file, so that the underlying program can handle the selection in an appropriate manner (open it, delete it, copy it, and so forth). It’s that simple, at least for a simple

JFileChooser

.

Tailoring the filters

Filters are a mechanism you can use to manipulate what the user can select, and, more importantly, manipulate what the user initially sees when first displaying

JFileChooser

. The last thing a user wants to do is scroll up and down a directory tree, hunting through every file in the system, looking for a specific file. For example, if you are writing an HTML editor, then the user will initially want to see only files with

.html

and

.htm

extensions. Later, when she wants to add a picture, she would only be interested in seeing image files (those with extensions like

.gif

,

.jpg

,

.tiff

, and so on). Therefore, you would want to filter the files so that only the image files are displayed to the user. To implement a file filter, you have to write a class that extends the

FileFilter

class, which is an abstract class, and implement the following methods:

  boolean accept(java.io.File file)
  String getDescription()

The

accept

method is the engine of the

FileFilter

class. The

JFileChooser

passes a file to the

FileFilter

objects and asks the

FileFilter

to determine whether or not it should be displayed to the user. The

FileFilter

code must answer the following questions:

1. If the file is actually a directory, then should this directory be displayed to the user?
2. Does the file have the extension(s) which the user wants to see?

getDescription

is the method that is used to populate the description box of the file filters (as shown in the figure above). These two methods will then be used to tailor the

JFileChooser

. As an example, the

HTMLFilter

subclass below displays only HTML files:

import java.io.File;
/**
Class to filter files for .html and .htm only
@author Jon Sharpe
*/
public class HTMLFilter extends
javax.swing.filechooser.FileFilter 
{
  /**
    This is the one of the methods that is declared in 
    the abstract class
   */
  public boolean accept(File f) 
  {
    //if it is a directory -- we want to show it so return true.
    if (f.isDirectory()) 
      return true;
  
    //get the extension of the file
    String extension = getExtension(f);
    //check to see if the extension is equal to "html" or "htm"
    if ((extension.equals("html")) || (extension.equals("htm"))) 
       return true; 
    //default -- fall through. False is return on all
    //occasions except:
    //a) the file is a directory
    //b) the file's extension is what we are looking for.
    return false;
  }
    
  /**
    Again, this is declared in the abstract class
    The description of this filter
   */
  public String getDescription() 
  {
      return "HTML files";
  }
  /**
    Method to get the extension of the file, in lowercase
   */
  private String getExtension(File f) 
  {
    String s = f.getName();
    int i = s.lastIndexOf('.');
    if (i > 0 &&  i < s.length() - 1) 
      return s.substring(i+1).toLowerCase();
    return "";
  }
}

Once you have created a filter, you can use it on files. This is handled internally by the

JFileChooser

dialog, and all you have to do is apply the filter to the

JFileChooser

class. There are two ways of applying the filters to the

JFileChooser

: by setting or adding them.

Setting filters

Setting the filter overrides

JFileChooser

‘s default action, which is *.*. Once you have set the filters, the default will become whatever you have set it to, rather than *.*.

  //fc declared as above
  fc.setFileFilter(new HTMLFilter());

Setting a filter will remove any filters that have been added or previously set.

Adding filters

When a filter is added to

JFileChooser

, it is appended to the list of filters already stored internally. In my experience, the last file to be added or set is the one that is first displayed to the user.

  //fc declared as above
  fc.addChoosableFileFilter(new HTMLFilter());

Fun and games

Swing has some problems and traps that can catch unwary programmers, just as other parts of the JDK and the Java class libraries do. Java 1.1 has a reputation for behaving unexpectedly; for example, it has inconsistent naming strategies, in which methods do not behave the way their names suggest. Most of these behavioral problems have been ironed out in Java 2, but there are still some pitfalls you’ll want to avoid. The

JFileChooser

is no exception; it has a couple traps that are absolute beauties. There are also ways that some thought can make coding and handling the

JFileChooser

a lot easier.

The loading trap

One thing most people don’t consider when they are creating, handling, and manipulating the

JFileChooser

is its performance on multiple platforms. I have an HTML tool that uses a

JFileChooser

dialog to let users select files. I initially had the

JFileChooser

create and populate itself when the Open command was activated. I developed and tested the code on a Windows 95 box, running JDK 1.3 beta, with four mapped drives (a floppy drive, two 1 GB hard drives, and my CD-ROM). It ran fine. I then moved the code over to a Windows NT box, running JDK 1.2, which has sixteen mapped drives, and it took nearly two minutes for the

JFileChooser

to appear. The reason: the Windows NT machine has nearly 200 GB of mapped drives, and the

JFileChooser

runs through all of that storage space in order to create its file map. Going through 200 GB takes time, especially when you’re trying to do it over a slow network. I had to find a way to hide the process of populating the

JFileChooser

from the user. My solution to the problem was to first make the

JFileChooser fc

a class object. Therefore, I had to create and populate it only once (so long as I did not set it to null after I had finished). All I had to do was alter and reset the filters on it to display different file types. Next, once the GUI HTML tool had finished loading and just before the constructor terminated, I started a separate thread and allowed the

JFileChooser

to populate in the background. I also disabled the Open menu item until after the

JFileChooser

had finished loading. There are, of course, tradeoffs that I made here:

• On bad days, when the network is really slow, it can take two or more minutes before the JFileChooser can be used.
• You only get one JFileChooser object to work with. This isn’t a major problem, but this object is always referenced, and it will always be populated, taking up memory and space.
• If you add a new file and don’t refresh the filters, you run the chance that new files will be missed when you display the JFileChooser.

The FileFilter trap

There are several problems with how the

JFileChooser

handles filters. These include:

• In Java 1.2, if you set a file filter, you will lose the default *.*. This has been fixed in Java 1.2.2 and later. If you don’t want a *.* option for some reason, however, there is no way to suppress it in Java 1.2.2 and later.
• In Java 1.2, if you set a file filter, it will be the default choice in the filter list. However, in Java 1.2.2 and later, the last filter you added will be the default in the list.

I have noted these problems on Windows platforms, so it may be a Windows-specific problem, rather than one that occurs on all Java VMs.

FileFilters

Creating a file filter class can be somewhat of a pain, as the vast majority of the code is purely replicated from any other class that you use to filter files. So why not write a generic class that can handle any type of file extension and have any type of description associated with the files being filtered?

GenericFileFilter

, provided in the

Resources

section below, is such a class. You construct it in the following way:

  String fileExts = {"html","htm"};
  //construct it giving it an array of file
  //extensions and a description string
  GenericFileFilter html =
    new GenericFileFilter(fileExts, "HTML Files");

This is a lot simpler. You can then use the created file filter in the same way as any other file filter.

A few general issues

The following is a list of general issues that are worth noting when using a

JFileChooser

.

1. Java does not have a notion of a current directory. The default for the system is the user.dir, which is picked up from the system properties.
2. When you are writing file filters, you only very rarely want to exclude the directories.
3. Filter text belongs in resource bundles if you expect to localize your application.
4. Load time can kill your application if it needs to pause for a few moments to load up the JFileChooser.
5. The filters on Java 1.2 and 1.2.2 (on Windows) behave differently, and not in the most logical ways. This might confuse the user.
6. Even though JFileChooser has the method getFileFilters, which returns an array of file filters, it does not have the methods setFileFilters(FileFilter[] in) or addChoosableFileFilters(FileFilter[] in). Again, this is somewhat illogical.

Conclusion

JFileChooser

is a simple and clean class that you can use to add an effective touch to your application. Because it is a Swing component, the actual look and feel will vary from platform to platform, leading users to believe that they are using a native tool rather than cross-platform Java.

JFileChooser

does have some features that make it illogical and tricky to program, as well as difficult for the user to understand. However, careful programming and a small amount of thought can bypass most of the problems.

Jon Sharpe has a BS in aapplied chemistry and
a MS in parallel computer systems. He has been programming in Java
for more than three years, and Swing for nearly eighteen months.
Currently, he is working in London as a Java programmer for a UK
bank. In his spare time, he enjoys writing Java code, as well as
acting and singing in a local amateur drama group in west London.

Source: www.infoworld.com