When to remove listeners (or not)...

[Joachim Wesner]

Hi,

when extending one of my recent plugins (the idea was that I have a plugin
that creates two image windows from an "extended"  ImageProcessor and I
added a dialog to automatically close the "child window" when the parent
was closed, I noticed sometjhing unsual that I at first did not understand.
Now I seem to understand, but I´m now insecure if I am writing unsave code
recently.

Question: Do I regularly need to remove any (ImageJ) listeners I use? The
problem is, sometimes it is difficult to tell when exactly the object get´s
out of focus and I thought that the listener will automatically
removed when the object that uses it is GCed. (As I learned, you normally
should not use finalize in Java) Up till now, I have seen no problems with
not explicitely removing listeners (as for  ex. dialog listeners or mouse
listeners)

One special case however seem to be ImagePluses (or similar...?) Clearly
ImagePluses survive even if the plugin etc. that created them has removed
all references to those (So ImageJ keeps a reference somewhere, otherwise
all windows might disappear again as soon as a plugin that created them has
finished running) However, what I discovered is, that this reference is
also not removed when a window is closed (The respectively ImageListener
was still active as I could prove) Is this intended?

In the current situation it seems that removing an ImageListener is
somewhat tricky, somehow you need the ImageListener itself to detect the
closing event that can finally remove it....... :-))

(I have also seen examples that track WindowEvent.WINDOW_CLOSING to achieve
this)

What is the correct way? Any general suggestions on Listener removal?

Thanx

Joachim


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Michael Schmid]

Hi Joachim,

a good question! After thinking about it, here is what I could find  
out (hopefully correct?)

_________________________________________________________________

Before going into details concerning removing listeners, it seems  
that there is a common misconception concerning ImageListeners. An  
ImageListener does not listen to a single image.

    * An ImageListener listens to ALL images. *

addImageListener is a static method, you can call it even if there is  
no open ImagePlus.

_________________________________________________________________

If an object registers as Listener (to whatever), it will be entered  
into a Vector (list of registered listners) where it registers.  
Unless you call the appropriate removeListener, the reference in the  
Vector will prevent the object from being garbage collected until the  
the Vector itself will become obsolete and prone to garbage collection.

So, for a GenericDialog, if you register as DialogListener, you need  
no 'removeDialogListener' because closing the dialog will make the  
dialog and, hence, the Vector of registered DialogListeners obsolete.  
It is the same, e.g., for a MouseListener if the Component where it  
has registered becomes obsolete.

For an ImageListener it is different: It is a *static* vector. If you  
register and object as ImageListener and never call  
removeImageListener it will prevent your object from the  
GarbageCollector; also your object's imageOpened, imageClosed,  
ImageUpdated methods will be called forever until ImageJ itself is  
terminated.

A finalize() method won't help; it would be called only if your  
object is ready for garbage collection. This will never happen as  
long as there is a reference to the object in the Vector of  
registered ImageListeners.

Thus,

   * Any object that registers by addImageListener MUST call  
removeImageListener when it becomes obsolete (e.g., in the close()  
method). *


Well, I think that I have to check my code for how often I have  
forgotten this...


Michael
________________________________________________________________

On 22 Sep 2009, at 00:00, Joachim Wesner wrote:

> Hi,
>
> when extending one of my recent plugins (the idea was that I have a  
> plugin
> that creates two image windows from an "extended"  ImageProcessor  
> and I
> added a dialog to automatically close the "child window" when the  
> parent
> was closed, I noticed sometjhing unsual that I at first did not  
> understand.
> Now I seem to understand, but I´m now insecure if I am writing  
> unsave code
> recently.
>
> Question: Do I regularly need to remove any (ImageJ) listeners I  
> use? The
> problem is, sometimes it is difficult to tell when exactly the  
> object get´s
> out of focus and I thought that the listener will automatically
> removed when the object that uses it is GCed. (As I learned, you  
> normally
> should not use finalize in Java) Up till now, I have seen no  
> problems with
> not explicitely removing listeners (as for  ex. dialog listeners or  
> mouse
> listeners)
>
> One special case however seem to be ImagePluses (or similar...?)  
> Clearly
> ImagePluses survive even if the plugin etc. that created them has  
> removed
> all references to those (So ImageJ keeps a reference somewhere,  
> otherwise
> all windows might disappear again as soon as a plugin that created  
> them has
> finished running) However, what I discovered is, that this  
> reference is
> also not removed when a window is closed (The respectively  
> ImageListener
> was still active as I could prove) Is this intended?
>
> In the current situation it seems that removing an ImageListener is
> somewhat tricky, somehow you need the ImageListener itself to  
> detect the
> closing event that can finally remove it....... :-))
>
> (I have also seen examples that track WindowEvent.WINDOW_CLOSING to  
> achieve
> this)
>
> What is the correct way? Any general suggestions on Listener removal?
>
> Thanx
>
> Joachim
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________