I am running into the problem of the "hanging JFileChooser" as described in the following threads:
http://forums.sun.com/thread.jspa?threadID=5309960
http://forums.sun.com/thread.jspa?threadID=724817
http://x86.sun.com/thread.jspa?threadID=5275999&messageID=10156541
I am using JVM 1.6.0_07-b06. It happens on Windows XP as well as on Windows Vista.
Has anybody found a workaround for this yet?
-
I've run into this myself and the updates didn't help. Strangely enough, removing all zip files (particularly large ones) from my desktop (JFileChooser's default location) solved the issue.
dkp : I do not have any zip files on my desktop nor in the file chooser startup locationbcash : Sorry that didn't help. As an FYI, here the link to the discussion regarding JFileChooser and large zip files on the desktop http://forums.sun.com/thread.jspa?threadID=5207221&messageID=9901574Zombies : Oh man, this sure helped ME. I can't get how Java is getting THIS ridiculous now. I have been using it at college/hobby and ofc work for going on 9 years now and it is really getting annoying. -
There's a bug where if you a networked drive mapped on the desktop, it can sometimes hang on the JFileChooser. That or it might be a shortcut to a networked drive. Something along those lines...
Tom Hawtin - tackline : A second floppy drive (remember them?) might also be a problem I think. -
The .10 update is supposed to fix the zipfile related one.
-
Yes, it was a bug, but I believe recent versions of Java no longer have it.
There are a few workarounds(although they are all dirty hacks):- Use a thread to wait until it was initialized
- Reuse the same JFileChooser(store it in a variable) instead of creating new ones. If possible, lazily initialize them:
public static JFileChooser chooser = null; public static void doSomething(){ if(chooser==null) chooser = new JFileChooser(); //use JFileChooser }This way your users have to wait less... but they still will need to wait. The only way to really fix this is to update your JRE.
0 comments:
Post a Comment