Memory Leak issue

A little off topic, but anyway:

It seems that the windows look and feel leaks memory at least in existing versions (1.4.x) This is particularly true if you use the JDesktop with InternalFrames.

I don't know if IDEA uses internal frames (it probably does?) but for me the usage experience is better if I switch to Metal (Java) look and feel.

With windows look and feel my hard drive constantly 'shuffles memory' at short intervals and IDEA becomes more and more memory hungry. This behaviour is almost non existent with Metal look and feel. My laptop stays silent if I'm not actively doing anything with the IDE.

A question to IDEA Developers:
Does IDEA use InternalFrames?
Have you profiled the IDEA and noticed the memory leak?
Have you contacted SUN or submitted a bug report?

This seems very frustrating to me. We are supposed to implement windows applications with Java and even the basic functionality is broken.

Here's an example of SUN code that clearly shows one of the bugs. (It's still not fixed)


Notice that the currentFrame variable is never cleared! Even if you close/dispose/destroy/whatever the InternalFrame the Desktop component will have a reference to it. So it's never GC:d.

There are lots of other bugs too. I know this becouse I tried to overcome this problem by using reflection to null that currentFrame reference after the InternalFrame was disposed. Still the only way to run our app which uses internal frames is to use Java look and feel + this code snippet in overridden dispose method of InternalFrame

2 comments
Comment actions Permalink

First of all I seriously doubt Idea uses internal frames. Where would it be using it? What frame in Idea can you drag around within another window?

By "windows" look and feel do you mean the "Idea" look and feel (the default)? Or do you actually mean the windows look and feel?

Kirk

0
Comment actions Permalink

Hezekiel wrote:

A question to IDEA Developers:
Does IDEA use InternalFrames?


No. IDEA doesn't use internal frames

Have you profiled the IDEA and noticed the memory leak?


Periodically we are profiling IDEA and found memory leaks in Swing. In
general we are fixing it by ourself (leflection, workaronuds, etc).

> Have you contacted SUN or submitted a bug report?

Of course, we are posting bug to SUN but actually it's useless.
Personally I've posted about 10 bug and no one has been fixed yet.

Best regards,
Vladimir Kondratyev
_____________________
JetBrains


This seems very frustrating to me. We are supposed to implement windows applications with Java and even the basic functionality is broken.

Here's an example of SUN code that clearly shows one of the bugs. (It's still not fixed)

 public class WindowsDesktopManager extends
> DefaultDesktopManager implements java.io.Serializable
> {
>   /* The frame which is currently selected/activated.
>    * We store this value to enforce MDI's single-selection
> model.
>    */
>   JInternalFrame currentFrame;
>   JInternalFrame initialFrame;	  
> 
>   public void activateFrame(JInternalFrame f)
>   {
>     try
>     {
>       super.activateFrame(f);
>       if (currentFrame != null && f != currentFrame)
>       {
>         // If the current frame is maximized,transfer that 
>         // attribute to the frame being activated.
>         if (currentFrame.isMaximum() &&
>             (f.getClientProperty("JInternalFrame.frameType") !=
> 		    "optionDialog") )
>         {
>           currentFrame.setMaximum(false);
>           f.setMaximum(true);
>         }
>         if (currentFrame.isSelected())
>         {
>           currentFrame.setSelected(false);
>         }
>       }
> 
>       if (!f.isSelected())
>       {
>         f.setSelected(true);
>       }
>       currentFrame = f;
>     } 
>     catch (PropertyVetoException e) {}
>   }
> }
> ]]>


Notice that the currentFrame variable is never cleared! Even if you close/dispose/destroy/whatever the InternalFrame the Desktop component will have a reference to it. So it's never GC:d.

There are lots of other bugs too. I know this becouse I tried to overcome this problem by using reflection to null that currentFrame reference after the InternalFrame was disposed. Still the only way to run our app which uses internal frames is to use Java look and feel + this code snippet in overridden dispose method of InternalFrame

 ((ActionMap)UIManager.getLookAndFeelDefaults().get
> ("InternalFrame.actionMap")).remove( "showSystemMenu" );
> ]]>


0

Please sign in to leave a comment.