Posted by
Michael Schmid on
URL: http://imagej.273.s1.nabble.com/When-to-remove-listeners-or-not-tp3691065p3691066.html
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> ______________________________________________________________________