Poor performance with JFileChooser

Miscellaneous Topics
#1

So quick question for you all, why does JFileChooser have such poor performance sometimes?

It’s not really critical as I’m only using it for the level editor, but occasionally the JFileChooser will hang for almost a minute (rarely more than that). The thing is, this doesn’t always happen. It’ll happen after using the program for a while, or immediately after start up (within 30 seconds), sometimes it’ll never happen, sometimes it always happens. There doesn’t seem to be any consistency.

I’ve heard that certain file associations can mess it up, but I have the path set to a folder with only .lvl files that don’t have an association. These files are are all less than 5mb and it doesn’t matter if there’s only one file or twenty files, sometimes the filechooser hangs sometimes it opens immediately.

FYI, I’m on windows 8.1 pro and I have not tried this on other machines. Any ideas?

#2

I’ve never seen this happen. Can you show us an MCVE that demonstrates the problem?

#3

did you test it with a very restrictive filter ? [icode]chooser.setFileFilter(filter);[/icode] … maybe that could exclude the file-assoc. trouble, if at all.

try setting a default directory that is not near root, maybe you have a funky usb drive or network mapped one which is slowing things down. [icode]chooser.setCurrentDirectory(“some/path”);[/icode]

i would also try to set the directory filter and see if that helps : [icode]chooser.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);[/icode] or [icode]chooser.setFileSelectionMode(JFileChooser.FILES_AND_DIRECTORIES);[/icode]

maybe its linked to hidden files [icode]chooser.setFileHidingEnabled(true);[/icode]

or maybe it’s linked to drag and drop : [icode]chooser.setDragEnabled(false);[/icode]

bit off-topic : here’s a nice trick to force “detail-view” by default :

Action details = chooser.getActionMap().get("viewTypeDetails");
if(details != null) details.actionPerformed(null);

apply all of this before you show the filechooser.

last thing that i can think of is the show-procedure itself :

if(chooser.showOpenDialog(someJFrame) == JFileChooser.APPROVE_OPTION) // <- this blocks
{
  // 
}
else
{
  //
}

maybe the blocking is screwing you over. do you open it from the EDT ?

#4

Well here’s the code

JFileChooser fc = new JFileChooser("./resources/levels");
fc.setDialogTitle("Save .lvl File");
fc.setFileSelectionMode(JFileChooser.FILES_ONLY);
FileNameExtensionFilter filter = new FileNameExtensionFilter("Level File", "lvl");
fc.setFileFilter(filter);
int return_val = fc.showSaveDialog(null);
if(return_val == JFileChooser.APPROVE_OPTION)
{
     //Do Stuff
}

Will try the hidden files and drag/drop, but I don’t see how it should care, the dir literally only has lvl files.

Edit, FYI this is the line it hangs on

JFileChooser fc = new JFileChooser("./resources/levels");
#5

Maybe java has no idea which folder it is in ATM and searches all the directories available on your computer to find it?

#6

wth? OK that’s plausible, but if I don’t provide a path it always goes to the project folder…so I’d assume it knew where it was…

#7

It knows where it is. It’s a relative path.

#8

Guyz, chill o-o

I’m just throwing random ideas which might hit the jackpot o-o

Isn’t that how debugging works?

#9

Wasn’t trying to be rude. I said that cause JFileChooser could’ve been set up to to search for a provided path vs just knowing that it’s relative, which is stupid cause it’s relative by default…hence the wth.

So, I’m still at a loss, maybe I should use setCurrentDir() rather than provide the path at initialization to see if that clears it up.

#10

Try removing the dot from file path. I remember using JFileChooser, didn’t have such a problem.

#11

Make sure any anti virus isn’t messing with it, usually if I ever have issues involving the hdd, it’s because AV is in the middle of a scan or similar.

#12

Fails without the dot, loads Documents folder instead.

I’m using defender, and it would have to be scanning every time I turn on my computer, not likely, but I’ll shut it off and see.

#13

the path constructor (FileSystemView) could cause some troubles but i dont think using the no-args constructor will help. [icode]setCurrentDirectory()[/icode] behaves the same in the end.

my last bet is the LookAndFeel, which one do you use ? thats the only thing that i can think of which could screw things up at construction. do you create the chooser in the EDT ?

#14

Here’s my look and feel, also EDT?

try {UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());} 
		catch (Exception e) {e.printStackTrace();}
#15

try [icode]UIManager.getSystemLookAndFeelClassName()[/icode]

should be [icode]com.sun.java.swing.plaf.windows.WindowsLookAndFeel[/icode] or [icode]com.sun.java.swing.plaf.gtk.GTKLookAndFeel[/icode] for gnome/linux or [icode]com.apple.laf.AquaLookAndFeel[/icode] for OSX or [icode]com.sun.java.swing.plaf.motif.MotifLookAndFeel[/icode] worst case.

#16

gross…windows look and feel = bleh…it seems to be handling it better right now, hopefully it keeps up.

I’ll post back either way.

#17

:stuck_out_tongue:

#18

This is the most infamous JFileChooser performance bug, but you’d have to be running a pretty old JVM to hit it (JDK6 pre-u10).

#19

With respect… no, that is not at all how debugging works.

Debugging works by consulting the API, documentation, and tutorials to check your assumptions.

In this case, assuming that Java has to search the whole hard drive (what?) for the current directory is an invalid assumption, which the API, documentation, and tutorials can tell you.

Recommended reading:

http://docs.oracle.com/javase/tutorial/uiswing/components/filechooser.html
http://docs.oracle.com/javase/7/docs/api/javax/swing/JFileChooser.html

OP, where is this code being executed? If you just execute it from the main() method, does it still hang? Do you have any threading going on? Are you somehow tying up the GUI with a long-running task?

#20

It’s being called in an action listener

JMenuItem file_save = new JMenuItem("Save");
file_save.setPreferredSize(new Dimension(w, h));
file_save.addActionListener(new ActionListener()
{
	public void actionPerformed(ActionEvent e)
	{
             //Goes here.
        } 
});

The call goes through immediately, but hangs when the JFileChooser is created.

I have Java 7u67 on my machine, but I’m using Java 7u45 64 bit and Java SE DK 7u45 64 bit to run/develop with.