2 mins to create a JFileChooser

Newbie & Debugging Questions
#1

Yes its me again. I wanted to add save/load feature to the game I’m making and I wanted to use the JFileChooser.

On my system P4 1.6ghz Java VM 1.4.2, it literally takes like 2 minutes to create one new JFileChooser object. So this made the game startup way to slow.

So I went to using the FileDialog class from AWT and the FilenameFilter doesnt actually work on my system even though I made my FilenameFilter class, filled in everything right and added it the FileDialog object.

So, what I want to know is 1. Why does it take so long to create a JFileChooser 2. Is there some good fix’s/alternatives for making a load/save dialog box.

Thnx for your time.

#2

Thats weird, I’ve never had any problems with JFileChooser, opens in less then a second in both Linux and Windows on a similar machine. Guess you’ll have to post som source code for anybody to be able to help. But on the other hand it only takes two lines of code to create the file chooser


final JFileChooser fc = new JFileChooser();

int returnVal = fc.showOpenDialog(aComponent);

So there’s not much you can have done wrong :slight_smile:

You haven’t accidentally put the creation in some loop or anything like that?

#3

Nope creation’s not in a loop. I’m sure of that. I checked and rechecked, ran the -Xprof and -Xaprof to see if anything was going wrong then, I tried the FileChooserDemo from Sun and that does the same exact thing on my system :-/.

Also i didnt include that I use WinXp.

I would post the code but its the same as what you have stated. However, here is the game’s profiled output from it starts to when it makes the JFileChooser to when it hits the title screen.


Flat profile of 1.94 secs (179 total ticks): AWT-Shutdown

  Interpreted + native   Method
 16.7%     0  +     1    java.lang.Object.wait
 16.7%     0  +     1    Total interpreted

  Thread-local ticks:
 96.6%   173             Blocked (of total)
 83.3%     5             Class loader


Flat profile of 1.08 secs (100 total ticks): AWT-EventQueue-0

  Thread-local ticks:
 99.0%    99             Blocked (of total)
100.0%     1             Compilation


Flat profile of 88.12 secs (8174 total ticks): AWT-Windows

  Interpreted + native   Method
100.0%     0  +  8173    sun.awt.windows.WToolkit.eventLoop
  0.0%     0  +     1    sun.awt.windows.WToolkit.init
100.0%     0  +  8174    Total interpreted


Flat profile of 0.11 secs (10 total ticks): Thread-0

  Interpreted + native   Method
100.0%     0  +    10    sun.awt.windows.WToolkit.shutdown
100.0%     0  +    10    Total interpreted


Flat profile of 7.63 secs (685 total ticks): AWT-EventQueue-0

  Interpreted + native   Method
  1.5%     0  +     2    sun.awt.windows.WInputMethod.setConversionStatus
  0.7%     0  +     1    sun.awt.im.InputContext.class$
  0.7%     0  +     1    sun.awt.im.CompositionAreaHandler.<clinit>
  0.7%     0  +     1    javax.swing.LayoutFocusTraversalPolicy.accept
  0.7%     0  +     1    sun.awt.windows.Win32OffScreenSurfaceData.initSurface
  4.4%     0  +     6    Total interpreted

  Thread-local ticks:
 80.1%   549             Blocked (of total)
  1.5%     2             Class loader
 94.1%   128             Compilation


Flat profile of 7.63 secs (686 total ticks): AWT-Shutdown

  Interpreted + native   Method
100.0%     0  +     1    java.lang.Object.wait
100.0%     0  +     1    Total interpreted

  Thread-local ticks:
 99.9%   685             Blocked (of total)


Flat profile of 89.42 secs (8293 total ticks): main

  Interpreted + native   Method
 76.2%     0  +  6309    sun.awt.shell.Win32ShellFolder2.getAttributes0
  4.9%     0  +   404    sun.awt.font.NativeFontWrapper.registerFonts
  3.9%     0  +   322    sun.awt.shell.Win32ShellFolder2.getDisplayNameOf
  2.8%     0  +   236    sun.awt.shell.Win32ShellFolder2.getNextChild
  1.9%     0  +   158    sun.java2d.loops.Blit.Blit
  1.0%     0  +    85    java.io.FileInputStream.open
  0.8%     0  +    64    sun.awt.shell.Win32ShellFolder2.getEnumObjects
  0.6%     0  +    50    sun.awt.windows.WToolkit.sync
  0.5%     0  +    42    java.io.WinNTFileSystem.getBooleanAttributes
  0.5%     0  +    40    java.lang.ClassLoader$NativeLibrary.load
  0.4%     0  +    35    java.io.RandomAccessFile.setLength
  0.3%     0  +    27    java.io.FileInputStream.readBytes
  0.3%     0  +    27    sun.awt.windows.Win32BlitLoops.Blit
  0.3%     0  +    23    sun.awt.shell.Win32ShellFolder2.initIDs
  0.2%     0  +    15    sun.awt.windows.WWindowPeer._setTitle
  0.2%     0  +    14    sun.awt.font.NativeFontWrapper.getFontMetrics
  0.1%     0  +    12    sun.awt.windows.Win32SurfaceData.initDDraw
  0.1%     0  +    12    sun.awt.windows.WDesktopProperties.getWindowsParameters

  0.1%     0  +    10    sun.awt.font.GlyphList.setupStringData
  0.1%     0  +    10    java.io.RandomAccessFile.close0
  0.1%     0  +     9    sun.awt.Win32GraphicsEnvironment.registerFontWithPlatfo
rm
  0.1%     0  +     5    java.io.WinNTFileSystem.canonicalize0
  0.1%     0  +     5    java.io.WinNTFileSystem.createFileExclusively
  0.0%     0  +     4    java.io.WinNTFileSystem.canonicalizeWithPrefix0
  0.0%     0  +     4    java.io.WinNTFileSystem.checkAccess
 97.2%    41  +  8008    Total interpreted (including elided)

     Compiled + native   Method
  0.1%    10  +     0    com.sun.imageio.plugins.gif.GIFImageReader.read
  0.0%     2  +     0    com.sun.imageio.plugins.gif.GIFImageReader.getCode
  0.0%     2  +     0    com.sun.imageio.plugins.gif.GIFImageReader.outputPixels

  0.0%     1  +     0    java.lang.String.indexOf
  0.0%     0  +     1    java.lang.StringBuffer.toString
  0.0%     1  +     0    java.io.StreamTokenizer.read
  0.0%     0  +     1    java.lang.String.getChars
  0.0%     1  +     0    java.nio.Buffer.<init>
  0.0%     0  +     1    TimeSmoothie.getAverage
  0.0%     1  +     0    java.util.Arrays.binarySearch
  0.0%     0  +     1    java.io.BufferedInputStream.read1
  0.0%     0  +     1    java.io.BufferedInputStream.read
  0.0%     1  +     0    vtable chunks
  0.3%    19  +     5    Total compiled

         Stub + native   Method
  0.4%     0  +    34    java.io.RandomAccessFile.setLength
  0.1%     0  +    11    java.lang.StrictMath.pow
  0.1%     0  +     6    java.io.RandomAccessFile.writeBytes
  0.1%     0  +     6    sun.awt.shell.Win32ShellFolder2.getAttributes0
  0.0%     0  +     1    java.io.RandomAccessFile.seek
  0.0%     0  +     1    java.lang.StrictMath.floor
  0.0%     0  +     1    java.io.RandomAccessFile.length
  0.7%     0  +    60    Total stub

  Thread-local ticks:
  0.1%     9             Blocked (of total)
  1.7%   144             Class loader
  0.0%     2             Interpreter
  0.0%     3             Compilation
  0.0%     2             Unknown: no last frame


Global summary of 89.42 seconds:
100.0%  8320             Received ticks
  0.3%    26             Received GC ticks
  0.3%    21             Compilation
  1.8%   151             Class loader
  0.0%     2             Interpreter
  0.0%     2             Unknown code

Maybe that has some clue, not sure what sun.awt.shell.Win32ShellFolder2.getAttributes0 is. Maybe someone can see something abnormal with this?

EDIT: I tried installing and running it under JRE 1.4.2_05, no difference for either my app or FileChooserDemo from Sun.

#4

Even Windows Explorer sometimes takes a long time to enumerate some directories. Try setting the initial directory to some innocuous location that has no special content (just ordinary .txt files for example). Ideally FileChooser would fill its file list in the background …

#5

Well, I tried to set regular old FileChooser’s FilenameFilter right after its creation in the apps startup code. That still doesnt work ::slight_smile:

Second, the delay is the actual creation statment JFileChooser jfc = new JFileChooser(); in the apps startup code. It causes the whole app to hang for way to long. :-/

EDIT: O, sorry, I tried setting JFileChooser’s initial directory to something on my computer with nothing in it and it still hangs for to long.

#6

I think you should test the application on another computer, to see if the problem can be reproduced there. If Suns example code also runs slow it’s probably some issue with your computer.

I didn’t find any relevant bugs in the bug database, the closest was this one http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5084718. But it seems to only affect earlier builds of 5.0 beta. In the bug repport the slow down occurs when you have a slow network connection.

#7

I got it resolved ;D!

For WinXP users with this problem check out http://forum.java.sun.com/thread.jsp?forum=57&thread=437304&start=30&range=15&hilite=false&q=>

I just turned off WinXP’s default file association with zips and bam, works like a charm.

To turn it off if you have the problem,

regsvr32 /u %windir%\system32\zipfldr.dll

To turn it back on if you need it, (I’m getting winzip, screw XP!)

regsvr32 %windir%\system32\zipfldr.dll

#8

Something which sounds similiar is a problem I had when opening a color chooser dialog. On my home computer with XP its works fine. On my work XP computer, it took forever to open up.

Very weird.

Dr. A>

#9

In WinXp when you open any form of explorer, open/load/save dialog or similiar, windows will always start to examine the files in the current directory and for certain file types (mp3, avi, zip …) extra information is extracted from the file. This is done by a separate thread but for some reason it hangs the explore window when examine a file. But during the time for switching from one file to another the explore window can be used.

For mp3, length, artist, album, are extracted from the ID2/3 tag.
For Avi the total length of the movie are extracted.
For zip the total amount of files are extracted.

These extraction of extra data takes a long time if the file are large, for example a 700mb avi file takes for ever and can sometimes lock the computer until the length has been extracted. For zip files as mention abow the time to examine the a large compressed file can take up to some minutes. At work we compress all our configuration files (xml) for our J2EE platform and it contains about 10000 files (40mb compressed). When trying to explore in the same directory as this zip-file windows hangs forever or so it feels.

So use the abow to disable the zip examine. There is another .dll for the avi that can be uninstalled to but I don’t remember the name of it.

The MS designer that thought a computer could examine large files in a flash should be shoot.

#10

Amen ;D

#11

Sounds more like they need to learn how to do multi-threaded programming. No surprise that they suck at that though. They still use “drive letters” and munged 8.3 filenames for heaven’s sake! Soon as the OS moved slightly beyond MS-DOS, I think all the MS programmers became hopelessly lost :).