So, yesterday I did a bunch of tagging in JEmplode, and I left it open all day (because, why bother quitting..) after synching. Today I was doing something with Quartz Debug (You've got a Mac around there, right Mike? I don't know where you'd find this info in Windows) and I noticed that I've got 122 (about the number of tags I edited) jEmplode windows open in memory, most of them 420x400, which is (not coincidentally) the size of the tag editing window. There's also a few 564x150s ("are you sure" dialogs), 217x353s (?) and 290x80s (?).

Each one of the edit windows is using 676kBytes of buffer memory, so something like 70mb of memory is being used (well, paged out probably). `top` agrees,

PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE

465 JavaApplic   0.0% 36:27.90  16   325   391  63.4M   141M   128M   425M

So it would appear that either JE isn't releasing the windows like it should, or the JVM is keeping them around for no reason. Can anybody else confirm this? I'm on a dual 450 G4 w/ a gig of RAM and 10.2 (release, came early with new iMac).

Thanks for this info ... You have to call .dispose() on Frames in Java (one of the few places where you can't just rely on garbage collection). It's entirely possible that I missed this call for that window.

Mike

Talking of Frame and friends, remember the problems I had with re-using Frame objects?

I tracked it down on the Java Bug site. It seems that when you unmap a window, the window manager (or X - I'm not sure which) sends it an event to confirm it's been unmapped. AWT's response to this is to think, "Ah, I've been iconified" and sets the flag appropriately.

The workaround is something like

    public void show() {

        setIconified(false);    // workaround for Java bug 4509276

        super.show();

    }



    /**

     * This is a workaround for Java bug 4509276.  On 1.3.1, frames that have

     * been hidden are iconified next time they are shown.  This fixes that.

     */

    private void setIconified(boolean b) {

        try {

            Class c = Frame.class;

            java.lang.reflect.Method m = c.getMethod("setState", new Class[] { int.class });

            java.lang.reflect.Field i = c.getField(b?"ICONIFIED":"NORMAL");

            m.invoke(this, new Object[] { new Integer(i.getInt(this)) });

        } catch (Exception e) {

            // Do nothing - the workaround isn't necessary on platforms that

            // don't have the setState method.

        }

    }

If you have a JDC account, look at Java bugs 4509276 and 4099787 for more background.