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 >
