<AWT Dev> Memory leaks due to static references in AWT & Swing

[Roman Kennke]

Hi Jaroslav,

> >## 20. 7. 2011 09:41:01 ##<
> > I wonder if those statics shouldn't be AppContext or even instance
> > fields in the KFM? Static fields just seem wrong.
> 
> Instance fields are not going to be much useful. There is singleton instance 
> of KeyboardFocusManager. From this point of view, it makes little difference 
> if the fields are instance or static ones.
> 
> The basic problem is that KeyboardFocusManager's lifecycle spans from 
> beginning till the end of the (UI) application. Yet it references objects 
> which are supposed to live shorter like various components and windows (e.g. 
> one can expect that if a component is not in AWT hierarchy and is not 
> referenced by any client code, it can be GCed, I hope). 

That makes sense, and I agree the KFM should not hold onto those
objects.

(I still would like to know from AWT experts if the static singleton KFM
should rather be a AppContext instance. And if those weak refs should
becomes instance fields instead of statics. I have a strong aversion
against static fields, especially if they represent state of what is
otherwise an object, even if it's a singleton.)

Another question is, when one of those components (focusOwner, permanentFocusOwner) are GCed, should this update the state of the KFM? I.e. should the focusOwner become another component?

Besides this, I think your change is good and even necessary.

Regards, Roman

> If the strong "GC ownership" of KeyboardFocusManager to invisible components 
> is weakened, our tests will be less influenced by internals of AWT and Swing.
> -jt
> 
> > Am Mittwoch, den 20.07.2011, 09:36 +0200 schrieb Jaroslav Tulach:
> > > Hello.
> > > My name is Jaroslav Tulach and I working on NetBeans. Recently I started
> > > to fight with memory leaks by writing some automated tests to verify
> > > that some sequence of actions does not leave a memory behind.
> > > 
> > > I think the tests are paying off, we managed to fix many leaks in
> > > NetBeans code. However now we are facing an unsolvable problem: there
> > > are some (temporary) leaks in AWT and Swing code which cause our tests
> > > to randomly fail.
> > > 
> > > We tried to workaround the problem (by opening new unrelated windows, or
> > > using reflection to clean well known references), but so far our
> > > solutions are fragile and the test continue to fail in new, inventive
> > > ways (for example https://netbeans.org/bugzilla/show_bug.cgi?id=197905).
> > > 
> > > It would be much easier if we could eliminate the (temporary) memory
> > > leaks in AWT/Swing code. I am attaching a patch that uses WeakReference
> > > instead of strong one that would fix one of our failing test.
> > > 
> > > What it would take to accept my patch? Thanks for your advice and help.
> > > -jt
>