Warning about JFileChooser filters and thread safety

[Larry Barowski]

Since Sun has not added this information to the
documentation as requested almost two years ago
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4770133 ,
I thought I'd post it here.

For file filters added to JFileChooser with addChoosableFileFilter(),
FileFilter.accept() will be called from threads other than the event
dispatching thread. accept() may be called simultaneously from
multiple threads for different FileFilters, or (unlikely but possible)
for a single FileFilter if it has been added to more than one
JFileChooser. Any code in FileFilter.accept() must be thread-safe
with respect to those possibilities.

For most filters that just use pattern matching on the filename, this
is not a problem. We ran into it because we use dynamic file types
(if the user tells us somefile.blah is a Java source file, then our
"Java source files" filter will accept it).

 

[Liz]

Since Sun has not added this information to the
documentation as requested almost two years ago
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4770133 ,
I thought I'd post it here.

For file filters added to JFileChooser with addChoosableFileFilter(),
FileFilter.accept() will be called from threads other than the event
dispatching thread. accept() may be called simultaneously from
multiple threads for different FileFilters, or (unlikely but possible)
for a single FileFilter if it has been added to more than one
JFileChooser. Any code in FileFilter.accept() must be thread-safe
with respect to those possibilities.

Maybe I am confused, but isn't there a different instance of "accept()"
for each FileFilter?

 

[Larry Barowski]

Maybe I am confused, but isn't there a different instance of "accept()"

for each FileFilter?

Sure, but you can add one FileFilter instance to more than one
JFileChooser, and each JFileChooser will start a separate thread
to do the filtering. In that case, accept() itself would need to be
thread-safe.

A more common problem would be that you access a cache from
accept() and that cache may be modified by your event handling
code elsewhere in the application. Then access to the cache must
be made thread-safe.

If you only use JFileChoosers in modal dialogs, problems would
be less likely than if you have them in modeless dialogs, or
embedded in a larger gui. For modal JFileChoosers, maybe
accept() would only have to be thread safe with respect to
any method that could be called when handling events generated
by the file chooser itself (my example below violates this
condition).

Showing the files asynchronously using separate threads,
as JFileChooser does, is a good thing. If file display is
slow it allows you to change directories, cancel, etc.
before all the files are displayed. The multi-threading is
undocumented though, and it did take me by surprise.

Following is a rather contrived example demonstrating the
problem. If accept() was only called from the event dispatch
thread, this program would not throw a NPE, which it
will if you click "Cancel" before all the files are displayed.


public class TestFileChooser {

public static void main(String[] args) {
JFileChooser fc = new JFileChooser();
fc.addActionListener(
new ActionListener() {
public void actionPerformed(ActionEvent e) {
str = null; }
});
fc.addChoosableFileFilter(
new FileFilter() {
public boolean accept(File f) {
test();
return true;
}
public String getDescription() {
return "test"; }
}
);

fc.showOpenDialog(null);
}

public static String str;
public static void test() {
str = "test";
try {
Thread.sleep(1000); }
catch(InterruptedException e) {}
str.length();
}
}

 

[Liz]

Sure, but you can add one FileFilter instance to more than one
JFileChooser, and each JFileChooser will start a separate thread
to do the filtering. In that case, accept() itself would need to be
thread-safe.

Wow, lots of info in this message. Let me see, I have a simple GUI
with a single button that brings up the file chooser. If the file
chooser is open and I try to click the button again, I get some sort
of bell and it refuses to open a second file chooser. In fact, I cannot
click any buttons without getting the bell.

A more common problem would be that you access a cache from
accept() and that cache may be modified by your event handling
code elsewhere in the application. Then access to the cache must
be made thread-safe.

If you only use JFileChoosers in modal dialogs, problems would
be less likely than if you have them in modeless dialogs, or
embedded in a larger gui. For modal JFileChoosers, maybe
accept() would only have to be thread safe with respect to
any method that could be called when handling events generated
by the file chooser itself (my example below violates this
condition).

Showing the files asynchronously using separate threads,
as JFileChooser does, is a good thing. If file display is
slow it allows you to change directories, cancel, etc.
before all the files are displayed. The multi-threading is
undocumented though, and it did take me by surprise.

Following is a rather contrived example demonstrating the
problem. If accept() was only called from the event dispatch
thread, this program would not throw a NPE, which it
will if you click "Cancel" before all the files are displayed.


public class TestFileChooser {

public static void main(String[] args) {
JFileChooser fc = new JFileChooser();
fc.addActionListener(
new ActionListener() {
public void actionPerformed(ActionEvent e) {
str = null; }
});
fc.addChoosableFileFilter(
new FileFilter() {
public boolean accept(File f) {
test();
return true;
}
public String getDescription() {
return "test"; }
}
);

fc.showOpenDialog(null);
}

public static String str;
public static void test() {
str = "test";
try {
Thread.sleep(1000); }
catch(InterruptedException e) {}
str.length();
}
}

 

[Larry Barowski]

"Larry Barowski" <larrybarATengDOTauburnDOTeduANDthatISall> wrote in message

Wow, lots of info in this message. Let me see, I have a simple GUI
with a single button that brings up the file chooser. If the file
chooser is open and I try to click the button again, I get some sort
of bell and it refuses to open a second file chooser. In fact, I cannot
click any buttons without getting the bell.

So the gui designer used a modal dialog - that is not a
requirement. I have a gui where I can open one "Open",
one "Save As", one "Backup As", one "Print to File",
and one of various other accessory dialogs that use file
choosers, for each open editing window; one global
"Open File" dialog, one global "Multiple File Search"
dialog, etc. None of these dialogs are modal, so you
could have thousands of active JFileChoosers going at
once.

Making file chooser dialogs (or any dialogs) modal
when they don't have to be is lazy design in my opinion
Nothing should be modal unless it requires immediate
attention. It may take more work to make them
modeless, but the result is a more usable interface.

 

[Liz]

So the gui designer used a modal dialog - that is not a
requirement. I have a gui where I can open one "Open",
one "Save As", one "Backup As", one "Print to File",
and one of various other accessory dialogs that use file
choosers, for each open editing window; one global
"Open File" dialog, one global "Multiple File Search"
dialog, etc. None of these dialogs are modal, so you
could have thousands of active JFileChoosers going at
once.

So where do you put 1000 popup dialogs so you can see them all????

 

[Larry Barowski]

So where do you put 1000 popup dialogs so you can see them all????

Using the phrase "some sort of bell", you seemed to
imply in your previous post that JFileChoosers can
ONLY be used in modal dialogs, and so only one can
be active at a time. I pointed out that they can (and
often should) be used modelessly, and that having
1000 active at time was POSSIBLE. Now you have
responded by asking an inane question and using
an unnecessary number of question marks.

 

[Liz]

Using the phrase "some sort of bell", you seemed to
imply in your previous post that JFileChoosers can
ONLY be used in modal dialogs, and so only one can
be active at a time. I pointed out that they can (and
often should) be used modelessly, and that having
1000 active at time was POSSIBLE. Now you have
responded by asking an inane question and using
an unnecessary number of question marks.

-------- but it was you who said --------
None of these dialogs are modal, so you
could have thousands of active JFileChoosers going at
once.

 

[Larry Barowski]

-------- but it was you who said --------
None of these dialogs are modal, so you
could have thousands of active JFileChoosers going at
once.

I don't see your point. I said you could do it, not
that it is required or that it would be a good idea,
and I was using "thousands" to emphasize "more
than one", as was clear from the context. You
can also open thousands of documents in
MS Word, thousands of browser windows in IE,
or thousands of applications in Windows.

 

[Liz]

I don't see your point. I said you could do it, not
that it is required or that it would be a good idea,
and I was using "thousands" to emphasize "more
than one", as was clear from the context. You
can also open thousands of documents in
MS Word, thousands of browser windows in IE,
or thousands of applications in Windows.

The point is that it is your idea, then
you criticize your own idea.

 

[Larry Barowski]

The point is that it is your idea, then
you criticize your own idea.

That doesn't make any sense. What idea did I present
and then criticize?

 

[Liz]

That doesn't make any sense. What idea did I present
and then criticize?

I'm getting bored.

 

[Larry Barowski]

"Larry Barowski" <larrybarATengDOTauburnDOTeduANDthatISall> wrote in message
I'm getting bored.

I doubt that. I won't post after this, since this thread
has gone far off-topic, but I should defend myself to
some extent. I began by presenting some information
that would have saved me several hours of debugging,
and saved our users many application crashes, if I had
had it earlier. My purpose was to help others avoid
the same mistake. I often read posts here that give me
that benefit.

You at first had a question, which I answered. Then
you had an objection, which though wrong, was
presented somewhat sarcastically. I responded to
your objection in a slightly annoyed tone that I felt
was considerably more polite than your sarcasm.
You then asked a pointless and off-topic question.
Perhaps you believe it was a valid question. Now I
think it is more likely that it was an effort to change
the subject because you felt that your previous two
posts make you look uninformed.

I have, once or twice, responded to posts in this
newsgroup with incorrect information. Rather than
change the subject, I have either pointed out my
mistake or apologized. For your third response in
this thread, "I see, JFileChoosers can be used in
places other than modal dialogs", or even "I think
most people only use JFileChoosers in modal
dialogs", would have been appropriate. No
response would have been fine as well.