Yes, that's another good point about weak listeners, although in
practice it might not be much of a problem unless the listener is doing
something that is no longer valid (or computationally expensive, but
that is less likely).
Another problem is that using weak listeners can let you avoid thinking
about the life cycle of the object and the listener. In cases where
there is a good point to explicitly free the listener, it is often
better to do so.
In most of the cases of skins, it's probably OK to remove the listener
as long as there is no functional problem with the listener disappearing
some unknowable amount of time after the object in question goes away.
if not doing that "doSomethingUseful" would cause a - more - terrible
misbehavior than a memory leak, would that mean that the
listening/update implementation in that specific case would have to be
re-thought? F.i. in the case of the ButtonSkin listening to control's
scene is changing global state which might be broken if it's not
reverted to not having a default/cancel registered? (what a horrible
sentence, sry ;)
Yes, something like that is what I meant. And the rethinking might lead
to a need for an explicit removal of the listener at the "right time",
or adding additional cleanup logic when the skin goes away.
-- Kevin
On 3/26/2020 4:58 AM, Nir Lisker wrote:
BTW, Tomas Mikula wrote about this on
http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html
.
There is a comment at the end that is worth a read too.
On Thu, Mar 26, 2020 at 1:53 PM Jeanette Winzenburg <faste...@swingempire.de>
wrote:
Zitat von Kevin Rushforth <kevin.rushfo...@oracle.com>:
Thanks for your input!
Glad we didn't miss the "minimum bar" height - with the java doc being
really clear on that :)
What I still don't quite get is the concern about "too early" and "not
cleaning up" - maybe I misunderstand the point entirely
As for whether the above is sufficient, it depends on what the
listener does (what its purpose is).In this simple example, it seems
unlikely that removing the listener when the instance of SomeClass
goes out of scope will cause any problems. It's worth looking at
what "doSomethingUseful" does to see if unregisters anything that
ought to be unregistered (and now maybe won't be if the listener
goes away early).
if not doing that "doSomethingUseful" would cause a - more - terrible
misbehavior than a memory leak, would that mean that the
listening/update implementation in that specific case would have to be
re-thought? F.i. in the case of the ButtonSkin listening to control's
scene is changing global state which might be broken if it's not
reverted to not having a default/cancel registered? (what a horrible
sentence, sry ;)
Hmm ..
