I got an email from Sun’s bug database this morning. Bug 4057701 - Need way to find free disk space - was marked as closed, fixed. This bug has been open since 09-JUN-1997. If this bug was scotch I would have almost considered drinking it. Who says Sun isn’t responsive?
I’ve been coding only slightly longer than that bug’s been filed. It’s been 8 years? Wow; I feel old.
Damn. Now I’m going to have to move all code and projects over to 1.5, aren’t I? 
Btw, technically that is not as bug.
Its an RFE.
Coding java, I meant. But still coding generally much less than 30 years 
You are technically correct, which is of course the best kind of correct. Thank whom ever over at Sun fixed it for me.
I’ve filed some bugs with Apple on JFileChooser in DIRECTORY_ONLY mode which basically doesn’t work properly in OS X (there is no way to pick the directory you are currently in, something you can do in the windows JFileChooser, native Apple directory choosers, and the AWT FileDialog).
But Apple bugs are private which is annoying, I can’t drum up support unless I encourage people to file dupes.
Will.
DIRECTORY_ONLY mode doesn’t work properly on Windows either.
If you double click on a directory, you move into that directory AND the directory name is put in the File: edit box. When you press ok you get a duplicate of the last path component e.g. C:\Temp\Temp- VERY annoying.
It also has the completely wrong LOOK, since it should be matching the Windows Folder chooser at that point, not the file chooser.
Then there’s the fact that there doesn’t seem to be any way to initialize it to show the desktop view and that sort of stuff…
And of course the details view is broken - no sorting by clicking the column headings, which is one of the main reasons to use the details view.
And then there is the huge speed issues on windows, a simple setCurrentDirectory takes several seconds. Simply constructing the JFileChooser without ever showing it takes many seconds.
Basically the JFileChooser implementation is a disaster on multiple platforms - and what really bugs me is that it is SOOOO fundamental to the user experience. Users can’t load and save their files without running into these issues, it really hurts desktop apps. I just don’t understand why those bugs don’t get more votes, or why Sun doesn’t consider them a top priority.
Because no-one actually wrote or used any deskop-java applications until 2002. Didn’t you know this? Sheesh. Look, java was only ever written for doing server development - not serious server-work, of course, only beans and other stuff, a bit like scripting really: cross-platform, no native memory access, no DMA access, etc - so it’s just downright ungrateful of you to expect it to work for desktop apps.
Oh, come on - you mean you didn’t get the big joke, the one about AWT? You didn’t think Sun actually meant people to really write complete applications with it, did you? LOL.
* blahblahblahh goes back to waiting for generics to die horribly and for sun’s “strategic java decisions” team to come back to reality 
Well I almost exclusively do desktop apps, and it seems that they (Sun) are finally realizing that Java has a place on the desktop…
Shoot, finding the free disk space is useful on servers too isn’t it? 
And quite frankly I have no problem with generics. I assume it could be better (while breaking things or reducing interoperability with existing stuff), but it does what I need it to do. They weren’t going to please everyone no matter what they did with generics though.
Too damn right! It’s actually fatal not to know the free diskspace, because it means you cannot possibly code defensively to reduce logging when you’re running out of disk - which means when something goes wrong, not only do you lose the log messages, but your whole OS breaks (most tools won’t start - e.g. manpages! - without free disk space).
I hate how the native L&F Windows JFileChooser locks (some) systems up. If it wasn’t for that I would be using the native L&F.
grr
Some of these things seem quite trivial to me. I just hope they get fixed soon.
Will.