On Wed, Jul 20, 2011 at 12:43 PM, Roman Kennke <[email protected]> wrote: > Hi Oleg, > >> as far as I can see you suggest to replace strong references to >> focusOwner, permanentFocusOwner, focusedWindow, and activeWindow to >> weak ones. >> But do you have test which can prove that any of these fields cause >> real memory leak? >> As far as I know KFM is supposed to update these fields as soon as >> focus state has been changed, thus if >> you do have memory leak then it is a bug in KFM and your fix is just a >> workaround for the problem. > > That is a reasonable concern. > > What I know is that in one of the projects at my workplace we *are* > having problems with the KFM keeping the permenentFocusOwner even though > it should be GCed. I have no testcase though. > > The permanentFocusOwner seems to be reset only from removeNotify(), so I > guess the question is, could a component hierarchy go out of scope (in a > valid way) without having removeNotify() being called?
as far as I know, it should not (but we always may have some "inventive" program or bugs ;) > On the other hand, I would still like to understand why are those fields > static? Shouldn't they be instance in the KFM? KFM can be set by user and it is local to app context. Of course it would be better to have these fields non-static, but current implementation depends on this and someone will need to change significant amount of fragile code to do this. Oleg. > > Regards, Roman > > >
